Carnet de notes

Catégorie : Sécurité informatique

  • Des cher­cheurs piratent à distance un robot de chirur­gie

    Une équipe de cher­cheurs de l’uni­ver­sité de Washing­ton est parve­nue à pira­ter un robot de chirur­gie télé­com­mandé à distance en exploi­tant plusieurs failles de sécu­rité, notam­ment via la connexion Inter­net qui relie le prati­cien au robot. S’il faut évidem­ment renfor­cer la protec­tion du système, les solu­tions tech­niques exis­tantes ne sont pas forcé­ment compa­tibles avec les besoins de la chirur­gie robo­tique télé­opé­rée.

    — Futura Sciences

    Le problème c’est que ça ne surpren­dra aucun infor­ma­ti­cien. C’est même quasi­ment une certi­tude pour tous ceux là.

    Et ça me fait peur que le corps médi­cal puisse décou­vrir ça, ou que ce type de service ne soit pas sur des liai­sons spécia­li­sées, distinctes d’In­ter­net.

    À l’heure où les États-Unis créent des virus infor­ma­tiques pour impac­ter à distance le programme nucléaire de l’Iran, je n’ose penser à l’arme que ces robots hospi­ta­liers peuvent deve­nir.

  • Les FAI devront livrer à l’Etat toutes les infos sur leurs réseaux

    Dans le cadre de ce contrôle, qui pourra avoir lieu une fois par an (ou plus souvent en cas de défaillances), les FAI et héber­geurs concer­nés devront four­nir à l’ANSSI ou au pres­ta­taire privé agréé « notam­ment la docu­men­ta­tion tech­nique des équi­pe­ments et des logi­ciels utili­sés dans ses systèmes ainsi que les codes sources de ces logi­ciels« 

    En clair : En plus des boites noires et des accès directs, il est demandé tous les moyens pour que l’État puisse s’in­tro­duire de force dans les systèmes, en dehors des accès prévus pour ça. Sous couvert d’en véri­fier la sécu­rité, mais même la marmotte ne croit plus à l’em­bal­lage arti­sa­nal du choco­lat dans le papier d’alu. Ayez confian­ce…

    — via Nume­rama

  • Google Drops Support for Secu­rity Ques­tions

    Google Drops Support for Secu­rity Ques­tions

    …et fran­che­ment il était temps. Ces systèmes de ques­tions person­nelles sont tota­le­ment aber­rants. Bref, merci.

    Il s’agit géné­ra­le­ment de ques­tions dont on peut trou­ver la réponse avec un mini­mum de recherches sur le net. Les amis et les proches connaissent déjà toutes les réponses ou peuvent les obte­nir rela­ti­ve­ment faci­le­ment à force de discus­sion.

    À l’in­verse, mon profes­seur préféré ? La rue de là où j’ai habité petit ? J’au­rais plusieurs réponses possibles. J’hé­site à chaque fois. Il est même possible que certains de mes proches répondent plus rapi­de­ment que moi-même à ces ques­tions – tout en donnant la bonne réponse.

    Un ou plusieurs numé­ros de télé­phone, un ou plusieurs emails, une liste de codes de secours à usage unique… Google fait très bien tout ça. L’avan­tage de ces solu­tions c’est que même si quelqu’un usurpe le compte, le service client peut les réuti­li­ser pour authen­ti­fier le vrai proprié­taire des données.

    Tout au plus on pour­rait imagi­ner de deman­der au service de confir­mer cumu­la­ti­ve­ment par plusieurs moyens, du genre mon télé­phone de bureau, plus le numéro person­nel de mes parents, plus l’email de ma femme. Peu probable que quelqu’un réus­sisse à avoir accès aux trois simul­ta­né­ment sans que je n’en ai connais­sance. Si je perds vrai­ment tous mes accès, cette diffi­cul­tés sera surmon­table.

    Visi­ble­ment des gens se permettent de remettre en ques­tion les pratiques dont le coût est supé­rieur au béné­fice : Je vois des banques désor­mais sans ces claviers virtuels inutiles et je me rappelle Mozilla qui avait arrêté de deman­der le renou­vel­le­ment régu­lier des mots de passe.

    Bon, tout n’est pas gagné partout : Linke­din ne véri­fie pas les emails des nouveaux comptes, et ça ouvre de jolies failles chez tous ceux qui ont un « authen­ti­fie-moi avec Linke­din ».

    Photo d’en­tête sous licence CC BY par Zuerichs Stras­sen

  • We’ve streng­the­ned our passs­word complexity requi­re­ments

    1. We’ve streng­the­ned our passs­word complexity requi­re­ments. We’ve noti­ced that the recur­ring pass­word expi­ra­tion often results in the use a poor or weak pass­words. The new pass­word requi­re­ments are:

    • Mini­mum length for 16 charac­ters
    • Mini­mum of 4 words when using a pass­phrase (a sequence of unre­la­ted words)
    • Maxi­mum length of 100 charac­ters
    • No pass­words that reuse the same words too many times, contain a birth­date suffix/prefix, etc.

    We stron­gly encou­rage the use of pass­phrases, instead of a tradi­tio­nal pass­word with multiple charac­ter classes. Example pass­phrases are displayed on the pass­word reset site.

    2. We’re remo­ving pass­word expi­ra­tion enti­rely. After chan­ging your LDAP pass­word one last time, it will no longer expire. The only reason you will need to change your change your LDAP pass­word in the future is if it has been acci­den­tally leaked, or if one of your compu­ters/mobile device were lost, stolen, or compro­mi­sed.

    Je ne saurais trop remer­cier Mozilla d’avoir sauté ce pas, quand bien même je ne suis pas concerné. Les poli­tiques de mots de passe n’ont géné­ra­le­ment ni queue ni tête, et l’obli­ga­tion de chan­ger régu­liè­re­ment de mot de passe est proba­ble­ment la superbe mauvaise idée du siècle en termes de sécu­rité.

    Je râle encore contre tous ces sites qui ont une procé­dure de réini­tia­li­sa­tion mais qui t’em­pêchent de saisir de nouveau un mot de passe que tu avais oublié préa­la­ble­ment.

    Juste un point pour Mozilla : Pour les appa­reils perdus ou volés, la solu­tion est plus la possi­bi­lité d’avoir des mots de passe unique dédiés. Le mot de passe géné­rique n’est utile que là où il est tapé régu­liè­re­ment.

    Partout où le mot de passe est à demeure (par exemple la confi­gu­ra­tion du client email), le système devrait permettre d’uti­li­ser un mot de passe unique, dédié. Si l’ap­pa­reil est compro­mis on ne change pas le mot de passe géné­rique, on se contente de « griller » le mot de passe dédié dans la liste des auto­ri­sa­tions.

    Google le fait très bien pour ceux qui ont activé l’au­then­ti­fi­ca­tion en deux étapes.

  • Hygiène de sécu­rité

    Hygiène de sécu­rité

    Aujourd’­hui on véri­fie la sécu­rité.

    Les services en ligne « sensibles »

    Même en ne gardant que le prin­ci­pal, il faut penser à :

    • votre boite email (qui sert à la récu­pé­ra­tion des mots de passe de tous les autres comptes),
    • votre service de nom de domaine,
    • celle de secours (qui sert à la récu­pé­ra­tion du mot de passe de la boite prin­ci­pale),
    • votre service de backup,
    • vos services de stockage ou synchro­ni­sa­tion en ligne,
    • votre héber­geur de serveur en ligne si vous en avez.

    [ ] La première étape c’est s’as­su­rer d’avoir des mots de passe « sûrs ». Ça veut dire suffi­sam­ment longs et complexes.

    Suivant les préfé­rences c’est au moins huit carac­tères aléa­toires entre chiffres lettres et symboles, au moins 12 carac­tères avec des lettres rela­ti­ve­ment aléa­toires, ou au moins 15 carac­tères mini­mum si vous avez des suites de mots communs.

    Le l34t sp33k, l’in­ver­sion des carac­tères, l’ajout d’une année, et globa­le­ment la plupart des varia­tions auxquelles vous pour­riez penser sont testables en moins de quelques minutes donc n’ajoutent pas de complexité signi­fi­ca­tive.

    [ ] Seconde étape, s’as­su­rer que ces mots de passe sont uniques et vrai­ment diffé­rents (pas de simples varia­tions du même).

    Au grand mini­mum, s’as­su­rer d’avoir un mot de passe pour les services très sensibles diffé­rent du mot de passe que vous tapez tous les jours pour les services moins impor­tants. Ce mot de passe sensible ne devra être tapé que dans des espaces correc­te­ment sécu­ri­sés.

    [ ] Quand vous le pouvez, acti­vez l’ »authen­ti­fi­ca­tion en deux étapes ». C’est possible au moins pour Google, Gandi, Drop­box, iCloud. C’est fran­che­ment peu gênant vu la sécu­rité que ça apporte, ne pas le faire est limite une faute.

    [ ] Les « ques­tions secrètes » pour récu­pé­rer des comptes dont vous avez oublié les mots de passe sont de vraies plaies pour la sécu­rité. En géné­ral il est très facile d’en trou­ver la réponse.

    À vous de voir si vous préfé­rez tricher et mettre de fausses réponses (au risque de ne pas vous en souve­nir) ou si vous avez une grosse faille à cet endroit là. C’est le moyen d’ac­cès de la plupart des usur­pa­tions courantes.

    L’ac­cès depuis vos postes

    Tablette, télé­phone (même les « pas smart »), micro-ordi­na­teur, NAS de la maison…

    [ ] Tous doivent avoir un mot de passe à l’al­lu­mage et à la sortie de veille. Tous, pas d’ex­cep­tion.

    Sur les smart­phones et tablettes vous avez parfois la possi­bi­lité de mettre un « schema ». Ça fonc­tionne assez bien et c’est plutôt simple à déver­rouiller. Si vous n’avez pas d’autre choix, utili­sez le code PIN.

    Pour les autres les mots de passe doivent respec­ter les mêmes règles que pour les services en ligne.

    [ ] Tous ceux qui le peuvent doivent avoir un disque chif­fré. Micro-ordi­na­teurs, tablettes et smart­phones le permettent quasi­ment tous.

    Le coût en perfor­mance ou en batte­rie est quasi­ment nul sur les proces­seurs des 5 dernières années qui ont des circuits dédiés pour ces calculs.

    Sans ça n’im­porte qui avec très peu de connais­sances infor­ma­tiques peut passer outre votre mot de passe.

    Parfois il existe une procé­dure de récu­pé­ra­tion si jamais vous oubliez vos mots de passe, de façon à déver­rouiller le disque. Sur Apple par exemple ça utilise le compte iCloud. Dans ces cas, le compte utilisé pour la procé­dure de récu­pé­ra­tion doit être consi­déré comme sensible avec les mêmes règles que plus haut.

    [ ] Les mises à jour sont confi­gu­rées pour être télé­char­gées auto­ma­tique­ment, et instal­lées dès qu’elles sont dispo­nibles.

    [ ] Si vous enre­gis­trez vos mots de passe dans votre navi­ga­teur pour ne pas les ressai­sir à chaque fois, ce dernier doit avoir un « mot de passe maître ».

    Si en plus ces données sont synchro­ni­sées en ligne, le mot de passe qui gère le compte de synchro­ni­sa­tion doit être consi­déré comme sensible avec les mêmes règles que plus haut.

    [ ] Vous avez une poli­tique de backup auto­ma­tisé et testé pour toutes vos données impor­tantes. Bien entendu le compte qui permet d’ac­cé­der aux données de backup est à consi­dé­rer comme sensible.

    La machine qui reçoit les backup doit avoir un disque chif­fré et si vous faites appel à un service tiers le chif­fre­ment des données doit se faire côté client pour que le pres­ta­taire ne puisse pas déco­der les données.

    Tout ça est un mini­mum, main­te­nant imagi­nez quelqu’un qui connait la réponse à la ques­tion secrète de votre opéra­teur télé­pho­nique. À partir de ça il peut réini­tia­li­ser le mot de passe pour accé­der à votre compte. Là il a une inter­face pour lire et écrire des SMS. Il demande alors la réini­tia­li­sa­tion du mot de passe de votre boite email prin­ci­pale, qui se fait via SMS. À partir de là il réini­tia­lise le mot de passe de votre service de stockage en ligne, de backup, et de votre banque. Le voilà avec de quoi récu­pé­rer vos photos, même si vous les avez effacé, et peut être même de quoi faire des vire­ments. Situa­tion fictive mais on a vu des attaques bien plus inven­tives.

    Si vous avez lu jusqu’au bout (sérieu­se­ment ?) je suis curieux de savoir quelle propor­tion de ces bonnes pratiques vous vali­dez, ou si vous respec­tez tout en détail pour l’in­té­gra­lité de vos maté­riels et comptes sensibles.

    Photo d’en­tête sous licence CC BY-NC-SA par Steve Crane

  • TLS par défaut

    Il ne fallait qu’une heure pour le faire mais je ne l’avais jamais inves­tie jusqu’à présent. C’est main­te­nant fait : Cet espace utilise une connexion HTTP sécu­ri­sée par défaut.

    Le lien HTTP non sécu­risé redi­rige direc­te­ment vers la partie sécu­ri­sée. Cette dernière envoie l’entête HSTS pour bloquer ce choix.

    Remon­tez-moi toute diffi­culté.

  • Défi­nir son API : authen­ti­fi­ca­tion

    Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes ques­tions qui font écho avec mes propres reflexions.

    Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :

    • Pas de système de session avec point d’en­trée spéci­fique pour le login. Ça demande au client de se préoc­cu­per de l’ex­pi­ra­tion de la session et de son main­tient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus impor­tante pour le serveur. Sauf besoin spéci­fique, il faut rester en state­less : Chaque connexion contient ses propres infor­ma­tions d’au­then­ti­fi­ca­tion.
    • Pas d’au­then­ti­fi­ca­tion par IP, comme je le vois trop souvent. Outre que c’est un poten­tiel problème de sécu­rité, c’est juste quelque chose de diffi­ci­le­ment main­te­nable et c’est toujours au dernier moment quand on veut faire un correc­tif, une migra­tion ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
    • L’au­then­ti­fi­ca­tion HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour amélio­rer légè­re­ment la résis­tance aux inter­cep­tions, il faut stocker le mot de passe en clair côté serveur. Une authen­ti­fi­ca­tion HTTP Basic avec du TLS pour sécu­ri­ser la commu­ni­ca­tion me semble bien plus perti­nent, et aussi plus simple à réali­ser.
    • Le système fait maison est toujours la pire solu­tion, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problé­ma­tique qui touche la sécu­rité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous commu­nique­rez avec des tiers.
    • OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solu­tion finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globa­le­ment est une sphère contrô­lée que vous devriez préfé­rer.

    Au final il reste le choix entre l’au­then­ti­fi­ca­tion HTTP Basic, l’au­then­ti­fi­ca­tion par certi­fi­cat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :

    • OAuth s’il s’agit d’avoir une authen­ti­fi­ca­tion à trois pattes. Hors de ques­tion d’im­po­ser à l’uti­li­sa­teur final de saisir ses mots de passes dans un logi­ciel tiers. Pour une API qui veut créer un écosys­tème de logi­ciels clients (type twit­ter) c’est le choix quasi­ment imposé. Oui il y a des diffi­cul­tés pour le mobile ou pour ce qui n’est pas « navi­ga­teur », mais ces ques­tions sont désor­mais large­ment docu­men­tées. Pensez bien que choi­sir ce type d’au­then­ti­fi­ca­tion demande un réel travail (par exemple trou­ver l’er­go­no­mie pour permettre à l’uti­li­sa­teur d’au­to­ri­ser et reti­rer l’au­to­ri­sa­tion d’ap­pli­ca­tions tierces sur votre propre système)
    • HTTP Basic par défaut pour quasi­ment toutes les autres situa­tions. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffi­sam­ment sécu­risé si on passe par du SSL/TLS.
    • Et les certi­fi­cats clients avec SSL/TLS ? C’est une solu­tion qui semble plus inté­res­sante que l’au­then­ti­fi­ca­tion HTTP mais qui se révèle complexe pour pas mal d’in­ter­lo­cu­teurs. La valeur ajou­tée ne semble pas valoir la complexité supplé­men­taire si vous n’in­te­ra­gis­sez pas avec des entre­prises de taille signi­fi­ca­tive. J’y croyais beau­coup, mais fina­le­ment j’ai peu d’ar­gu­ment face à la simpli­cité du HTTP Basic.

    Et vous ? vous utili­sez quoi pour l’au­then­ti­fi­ca­tion de vos services ?

  • Triple vali­da­tion de mot de passe

    Non véri­fié mais ça semble une bonne idée :

    Face­book stores three hashes of your pass­word (let’s say it’s « pAss­word »):
    * « pAss­word » – the pass­word as it is
    * « PaSSWORD » – the pass­word, case inver­ted, in case you have caps lock on
    * « PAss­word » – the pass­word with its first letter capi­ta­li­zed, for those with mobile devices that insist on Capi­ta­li­zing Every­thing

    Comme indiqué dans un commen­taire, il n’y a pas forcé­ment besoin de stocker trois mots de passe chif­frés, on peut se conten­ter de modi­fier le mot de passe en clair par deux fois pour le faire corres­pondre aux diffé­rents types d’er­reur si le premier essai ne fonc­tionne pas.

    Pour la version « verrouillage majus­cule activé », je leur souhaite bonne chance dès qu’on touche au numé­rique ou aux ponc­tua­tions. Suivant l’agen­ce­ment clavier ça peut donner des centaines de combi­nai­sons. Heureu­se­ment que les gens n’uti­lisent pas de mots de passe sérieux.

  • Pour le paie­ment, les Austra­liens choi­sissent les empreintes digi­tales

    Le numé­rique et les nouvelles tech­no­lo­gies relèvent encore du fantasme pour certains. Ils ont plus l’im­pres­sion de vivre dans la science fiction qu’a­vec les réali­tés.

    Pour le paie­ment, les Austra­liens choi­sissent les empreintes digi­tales. C’est génial, on a l’im­pres­sion de vivre dans le futur, mais c’est peut être le seul avan­tage. Qui s’est posé la ques­tion des contraintes à vali­der ?

    Les empreintes digi­tales ça se vole et ça se fausse sans avoir une équipe qui s’ap­pelle Mission Impos­sible. La sécu­rité réelle est loin de ce qu’on imagine. Les empreintes digi­tales ce n’est pas pérenne non plus. On peut s’abi­mer le doigt : C’est souvent tempo­raire mais parfois perma­nent ou régu­lier. Oh, et on peut se servir de votre doigt après vous avoir donné un bon coup sur la tête.

    Le système de code secret n’est pas parfait non plus mais il a quelques avan­tages. Ceux qui font de la haute sécu­rité avec biomé­trie asso­cient toujours cette biomé­trie avec un système de code secret.

    Plutôt qu’en­vi­sa­ger le progrès tech­no­lo­gie comme un rêve de science fiction, et si nous nous occu­pions à résoudre les vrais problèmes de tous les jours ? Par exemple permettre de payer par carte les petits paie­ments, ou permettre à chacun de rece­voir des paie­ments par carte sur son compte bancaire sans avoir à monter un site de commerce élec­tro­nique avec des abon­ne­ments bancaires bien chers. Savoir si on utilise du NFC, de la biomé­trie ou un code secret, c’est fina­le­ment un faux problème.

  • Vol de mots de passe

    Drop­box a – encore – eu une faille de sécu­rité. Des mots de passe ont été volés. Visi­ble­ment le mien en fait partie.

    Hi Eric,

    Recently, pass­words have been stolen from some Inter­net services. This is a problem because many people use the same pass­word on multiple services, which is unsafe.

    As a precau­tion, we’ve reset your pass­word and you can create a new one here.

    We haven’t detec­ted any suspi­cious acti­vity in your Drop­box, but we’re proac­ti­vely taking steps to keep users safe.

    We know it’s easy to use a single pass­word across different websites, but this means if any one site is compro­mi­sed, all your accounts are at risk. If you’ve ever used the same pass­word for more than one website, you should create new unique pass­words for each of them. Tools like 1Pass­word do this for you and can help make your accounts safer.

    Best,

    – The Drop­box Team

    Des failles et des échecs ça arrive. Aucun service n’est immu­nisé, pas mal le vôtre super-sécu­risé.

    Point posi­tif : Ils commu­niquent dessus et prennent l’ac­tion la plus sensée à ce niveau en forçant un chan­ge­ment de mot de passe, au risque de bloquer tota­le­ment l’ac­cès à ceux qui ont changé leur email mais utilisent encore l’an­cien compte Drop­box. Ils commu­niquent aussi sur l’im­pact possible si on utilise un seul mot de passe pour plusieurs service, ce qui est très bien­venu.

    Sur les points néga­tifs tout de même : Ils ne précisent pas si le mot de passe a été déli­vré avec un hachage correct ou s’il a été divul­gué en clair. L’ab­sence de préci­sion implique un doute assez peu récon­for­tant.

    Les solu­tions

    Ce qui me gêne c’est qu’on retourne dans les solu­tions habi­tuelles qui sont bien en théo­rie mais pas les plus solides en réalité.

    Utili­ser un mot de passe unique par service ? C’est un délire pour l’es­sen­tiel des utili­sa­teurs et même pour les geeks c’est loin d’être évident. De ce que j’en ai vu même ces derniers utilisent géné­ra­le­ment un mot de passe unique pour les deux ou trois services prin­ci­paux (dont l’adresse email prin­ci­pale) mais après c’est un ou deux mots de passe communs pour l’en­semble des services suivant leur niveau de sécu­rité.

    Le conseil d’uti­li­ser 1pass­word est bon mais il est de peu d’aide en dépla­ce­ment, et ça reste un service à 50 $ pour le bureau­tique plus encore 15 $ pour la version iPhone.

    Drop­box affirme travailler à une authen­ti­fi­ca­tion en deux étapes, une par mot de passe et l’autre par un média plus person­nel, par SMS par exemple. C’est une très bonne nouvelle, mais c’est aussi agaçant. Je ne veux pas avoir 150 méthodes d’au­then­ti­fi­ca­tions en deux étapes, une pour chaque service, qui fonc­tionnent diffé­rem­ment à chaque fois. C’est encore plus vrai si, comme trop souvent, les SMS sont réser­vés aux rési­dents des États Unis.

    Voir autre­ment

    Il est vrai­ment temps de voir autre­ment et de ne pas cher­cher à réin­ven­ter la roue. Il est temps d’uti­li­ser des authen­ti­fi­ca­tions centra­li­sées comme Open ID, WebID, Brow­serID ou d’autres. L’avan­tage c’est qu’a­vec un seul (ou deux, trois) mot(s) de passe à rete­nir on peut le(s) faire très complexe.

    Mieux : On peut acti­ver une authen­ti­fi­ca­tion plus sûre, à base de certi­fi­cats SSL ou de relai par télé­phone. Ça devient possible parce qu’on ne passe pas par 150 services diffé­rents avec leurs méthodes diffé­rentes.

    J’ai fait le choix de Google parce que son authen­ti­fi­ca­tion en deux étapes me conve­nait et que l’au­then­ti­fi­ca­tion dépor­tée sur Google était une des plus répan­due. D’autres utili­se­ront un Open ID qui authen­ti­fie sur la base d’un certi­fi­cat SSL. Certains pour­ront utili­ser les deux ou encore d’autres solu­tions, suivant le service visé. Il y a le choix, y compris avec des proto­coles décen­tra­li­sés (désolé pour les termes, ça fait une authen­ti­fi­ca­tion centra­li­sée par un proto­cole décen­tra­lisé, vous pouvez propo­ser de meilleurs termes en commen­taire) si vous ne voulez pas repo­ser sur un acteur tiers.

    L’im­por­tant c’est d’ar­rê­ter de croire que la phase d’au­then­ti­fi­ca­tion doit forcé­ment se faire sur chaque service indé­pen­dam­ment. C’est quelque chose de trop sensible et trop parti­cu­lier pour croire qu’on a un réel béné­fice à réin­ven­ter la roue.