DEUXIÈME PARTIE :
PRÉMUNIR LA SOCIÉTÉ CONTRE LE RISQUE DE LA DÉPENDANCE NUMÉRIQUE

I. PREMIÈRE TABLE RONDE : LA SÛRETÉ NUMÉRIQUE DANS LA GESTION COURANTE

Présidence de M. Bruno Sido, sénateur, président de l'OPECST

M. Bruno Sido, sénteur, président de l'Opecst. Après avoir parlé ce matin de sécurité numérique et de résistance des systèmes aux attaques, nous abordons cet après-midi un sujet tout aussi important, celui de la sûreté intrinsèque de ces systèmes. Nous examinerons successivement les questions de l'étendue de l'exposition aux risques de défaillance, de la fiabilité des appareils servant au diagnostic en matière de santé et de la capacité à certifier la validité des systèmes numériques.

Comme un certain nombre d'entre nous, j'ai grandi dans une société sans ordinateur. Notre premier contact avec l'informatique se faisait par l'initiation à des langages aux intitulés étranges, comme le cobol ou le fortran, qui permettaient de faire fonctionner un ordinateur dont les calculs se traduisaient par un amoncellement de cartes perforées.

C'est une banalité de pointer l'ampleur des progrès accomplis depuis, mais j'ai la conviction que la numérisation de la société en est au stade où, comme le nénuphar, elle ne remplit que la dixième partie du bassin, avant d'en occuper la moitié demain et la totalité après-demain.

L'aviation civile est un bon exemple de cette progression car elle emploie des logiciels dits critiques, c'est-à-dire qui ne doivent pas connaître de défaillance. Le Concorde a été, en 1969, le premier appareil à être équipé de commandes de vol électronique. Aujourd'hui, les commandes de vol d'un A380 comptent plus d'un million de lignes de codes. Demain, d'ici 2025, la navigation aérienne sera assurée par un système entièrement numérisé dont les codes compteront des millions de lignes. Au stade ultime de cette évolution, les avions de ligne seront devenus des objets numériques pouvant rectifier en permanence leur trajectoire en fonction de leurs perspectives d'atterrissage, de la météo et du trafic aérien. Cet exemple nous permet de mesurer l'ampleur du défi qui nous attend.

Produire des logiciels est une chose, vérifier leur validité en est une autre. Le logiciel de conception des trains d'atterrissage de l'A380 est six fois moins volumineux que ses logiciels de vérification. Les écoles françaises de mathématiques ont développé, à compter du milieu des années soixante-dix, des instruments comme l'analyse statique et la vérification formelle qui s'assurent de la validité de systèmes de plus en plus massifs à moindre coût. En dépit de l'excellence de nos chercheurs dans ce domaine et de l'intérêt de nos industriels pour ces questions, je ne suis pas sûr que les pouvoirs publics français aient conscience de l'importance de ce qui se profile. C'est pourquoi je souhaite que l'Office, dont c'est la vocation, soit saisi de ces questions.

La première table ronde de cet après-midi va nous conduire à nous pencher d'abord sur l'importance prise par les systèmes numériques dans les dispositifs de gestion courante. Cette dépendance fragilise de facto toute l'architecture sociale. La crainte cataclysmique du fameux bug de l'an 2000 est une anticipation, certes exagérée, de ce phénomène. La question est de savoir à quelle vitesse la réalité va finir par rattraper ce type d'appréhension. C'est une interrogation que je soumets à M. Gérard Berry.

M. Gérard Berry, professeur au Collège de France, membre de l'Académie des sciences et de l'Académie des technologies . Je suis ravi que vous ayez pris l'exemple de la navigation aérienne, domaine dans laquelle la France était très en avance. Il était devenu impossible de piloter des avions de chasse à la main. En outre, l'informatique a permis une navigation plus économique, plus légère et surtout plus sûre.

Elle est désormais partout et ses applications sont innombrables. Je vais vous parler aujourd'hui de ses dangers, mais ceux-ci ne doivent pas faire oublier ses succès, qui sont plus importants.

Il y a deux grands dangers liés à l'informatique : les bugs et l'inculture informatique.

Il faut savoir qu'un programme informatique est un système qui exécute exactement et obstinément des ordres extraordinairement détaillés, y compris ceux qu'on n'aurait pas dû lui donner, d'où les bugs. Cela ne signifie pas que tous les systèmes engendrent des bugs. En avionique, l'extrême sophistication des méthodes de développement et de certification des équipements informatiques permet de les éviter. En réalité, les bugs sont dus au manque de soin dans la fabrication des applications. C'est le cas pour les téléphones portables, les industriels ayant d'abord le souci de sortir de nouveaux produits le plus rapidement possible pour conquérir des parts de marché. Il est vrai que la qualité des téléphones portables n'est pas un enjeu vital, à la différence de celle d'un avion. Les équipements informatiques posent également beaucoup plus de problèmes dans les voitures que dans les avions, parce que la règle de base des constructeurs automobiles est de réduire les coûts.

Le manque de culture informatique est peut-être plus grave, dans la mesure où il est plus difficile d'y remédier qu'à un simple problème technique. Pendant très longtemps, nos dirigeants ont relégué l'informatique à une place ancillaire. Cela s'explique par le fait qu'ils sont généralement dépourvus de toute formation dans ce domaine, voire du simple bon sens qui leur permettrait de comprendre à peu près comment cela fonctionne. Faute de cette qualité, on a tendance à projeter sur ce sujet les compétences apprises ailleurs. Je me suis ainsi rendu compte que les ingénieurs avec lesquels j'ai été amené à travailler sur le projet de navette Hermès appliquaient à l'informatique des raisonnements de mécanique.

Pour contrer les bugs, les informaticiens, tant les chercheurs que les industriels, développent des techniques de génie logiciel ou de mathématique formelle, domaine où la France excelle. Malheureusement les techniques de génie logiciel ne bénéficient pas de la même considération que les techniques de génie mécanique.

Il faut donc promouvoir les systèmes qui marchent, car ils existent : on n'est pas obligé d'utiliser des programmes qui ne fonctionnent pas ! Si la commande publique en matériel informatique n'était pas obnubilée par le critère du moindre coût, l'État risquerait moins de bugs, dont le coût peut se révéler important : récemment, un bug affectant la fabrication d'un des transistors du dernier Pentium a coûté un milliard de dollars à Intel.

L'autre remède, c'est l'éducation. Aujourd'hui que tout est numérique, il est grand temps que les ingénieurs et les dirigeants soient éduqués à l'informatique. L'éducation à l'informatique fait d'ailleurs l'objet de travaux de l'Académie des sciences. Il faut absolument que les parlementaires se saisissent de ce sujet crucial : nous ne serons pas en mesure de fabriquer des systèmes fiables et exportables tant que la culture informatique ne sera pas généralisée dans notre pays. Comme le disait Jean Vilar, « si vous trouvez que l'éducation coûte cher, essayez l'ignorance. »

M. le président Bruno Sido. Monsieur Marko Erman, comment percevez-vous les progrès de la numérisation globale de la société ? Ne risquent-ils pas de générer à terme un grave risque de système ?

M. Marko Erman, senior vice president, recherche et technologie, chez Thales et membre de l'Académie des technologies. Je voudrais vous sensibiliser à l'importance des données dans la société numérique. Notre société de l'information se caractérise par une production massive de données numériques de toutes sortes et la capacité de les interconnecter et de faire communiquer les personnes, les objets et les différentes organisations. Ces données sont en quelque sorte la matière première de la société de l'information. Elles représentent un enjeu économique, stratégique, voire culturel, majeur. C'est sur cet enjeu et ses risques associés que je voudrais centrer mon intervention.

Ces données viennent de partout et de tout le monde. Chacun de nous crée des données, soit de façon passive, à travers son identité numérique ou la dématérialisation d'actes administratifs, soit de façon active, par exemple en participant à des réseaux sociaux. Les entreprises, les banques, les institutions à travers leurs activités de production, de gestion, d'interaction avec les clients, en produisent beaucoup. De plus en plus de données sont également produites par des systèmes dits embarqués, qui, à travers différents capteurs, interagissent et recueillent des informations liées à leur environnement. En 2012, 2,5 Exabyte de données ont été produites chaque jour, soit dix fois plus qu'il y a à peine cinq ans, et 50 000 fois plus que la somme de toute la littérature de l'humanité. Ces chiffres donnent le vertige, et on pourrait les multiplier à loisir. Nous sommes entrés de facto dans l'ère des big data , c'est-à-dire des ensembles de données dont la taille va au-delà de la capacité actuelle des logiciels de gestion.

La problématique des données est indissociable de celle des réseaux de communication qui permettent de les échanger, de les stocker et de les consulter.

D'ores et déjà, toutes nos infrastructures - aéroports, gares, stations de métro, lignes ferroviaires, autoroutes, centrales d'énergie, etc. -, leurs systèmes de contrôle et les outils industriels sont interconnectés, voire connectés à Internet, directement ou indirectement, de manière permanente ou temporaire. Basés sur ces technologies de l'information - capteurs, données, communication -, des systèmes extrêmement complexes deviennent possibles, tels que les villes intelligentes, les smart cities ou les réseaux de distribution d'énergie du type smart grids .

Les systèmes qui pilotent nos infrastructures produisent beaucoup de données mais, dans la majorité des cas, ne les exploitent pas. Ils réagissent en fonction de celles « du moment » - alertes remontées par des capteurs, contrôle de la validité d'un titre de transport, par exemple - mais ne tirent partie ni du passé, ni de la totalité des données disponibles pour prendre ou proposer une meilleure décision. Ce n'est pas étonnant : jusqu'à récemment, le trop grand volume de celles-ci et les ressources de calcul nécessaires pour les traiter rendaient cette tâche difficile.

Aujourd'hui, les progrès dans le domaine de l'algorithmique - le réseau Internet, le cloud - et les capacités accrues de traitement des données sont autant d'atouts supplémentaires pour s'attaquer à ce défi. Des approches mathématiques adaptées doivent permettre d'extraire des informations pertinentes. Il est important de comprendre que ceci peut se faire hors hypothèses a priori : on découvre en quelque sorte l'information cachée. C'est bien cela qui donne au couple « données brutes - information extraite » une valeur économique et stratégique forte.

La valeur économique fonde le « business model » des grandes entreprises du web, telles Google, Facebook ou Twitter. L'objectif de ces sociétés est de collecter le maximum d'informations sur le plus grand nombre d'usagers possible pour leur offrir un service personnalisé. Des acquisitions récentes ont montré que la valeur de celles-ci est directement liée à la taille de leur base clients.

Lorsque le champ des données inclut des éléments relatifs aux activités industrielles, financières, au transport, à l'énergie, son caractère stratégique devient évident. Les grands pays, et d'abord les États-Unis, l'ont parfaitement compris. Ils en exploitent formidablement le potentiel économique. Mais des initiatives, comme le Patriot Act , montrent, s'il en était besoin, que la valeur stratégique des données est au centre des préoccupations liées à la sécurité nationale. Aujourd'hui, et plus encore demain, les grands pays qui connaissent un développement économique rapide, comme l'Inde, la Chine ou le Brésil, emprunteront le même chemin. Il est certain que ces pays voudront exploiter eux-mêmes cette matière première.

La France ne peut rester indifférente à ce qui est un enjeu majeur pour notre pays aussi, et, au-delà, pour l'Europe.

Pour relever ce défi, elle ne manque pas d'atouts, dont en premier lieu l'excellence de notre recherche en mathématiques - je rappelle que cette science est à l'origine des algorithmes nécessaires aussi bien à l'exploitation des données qu'à leur protection. C'est pourquoi elle doit être préservée et renforcée.

Le comité interministériel pour la modernisation de l'action publique du 18 décembre 2012 a présenté la transition numérique comme « un formidable levier de modernisation de l'action publique », porteur de valeurs « d'égalité, de neutralité, de transparence, d'efficacité et d'adaptation ». Cette transition comportera quatre volets : l'amélioration du service à l'usager ; le développement des services numériques ; l'ouverture de l'administration et des données publiques ; la modernisation des systèmes d'information.

La démarche « Open Data » et la création de la structure ETALAB s'inscrivent parfaitement dans ce souci d'ouverture des données publiques, permettant de créer de nouveaux services. C'est pourquoi il faut la soutenir. Cependant, si on veut se prémunir contre les risques potentiels, il est important de prendre en compte dès maintenant la problématique de la sécurité, en même temps que celle des formats et du stockage.

Ce qui est vrai pour les données publiques l'est encore plus pour toutes les autres.

Du coup, la question de la fiabilité et de la protection des informations devient cruciale. Elle nous ramène directement à la problématique sur les données dont elles sont extraites. Au-delà des problèmes de cybersécurité, absolument essentiels, il faut établir les conditions qui permettront d'assurer l'intégrité des données et la confiance numérique. Cela nécessite de maîtriser les technologies de stockage de celles-ci, les réseaux de transmission et bien évidemment l'analyse et l'exploitation.

On le sait, l'informatique en nuage offre des solutions économiques et performantes pour le stockage et est capable de fournir des services à la demande. Au travers de la création de sociétés comme CloudWatt et d'autres, la France commence à se doter de solutions de cloud sécurisées. C'est absolument nécessaire dans ce contexte.

Le réseau Internet, qu'il soit fixe ou mobile, assure l'indispensable interconnexion entre tous ses points - serveurs, capteurs, usagers, etc. Il est considéré comme intrinsèquement résistant aux chocs puisqu'il s'agit d'une immense toile qui peut supporter la perte d'un ou plusieurs noeuds de connexion. Cependant, si, dans sa description logique, il se compose de plusieurs centaines d'opérateurs, offrant ainsi de la redondance, le réseau physique a, quant à lui, une réalité moins diversifiée. Certaines catastrophes naturelles récentes ont montré la fragilité des réseaux de communication. Il est donc également essentiel d'améliorer leur résilience. Pour ce faire, il est nécessaire que l'analyse des risques prenne en compte les cas exceptionnels, voire aberrants.

J'ai essayé de vous faire partager ma conviction que les données vont jouer un rôle essentiel dans la société et l'économie numérique. Leur valeur économique et stratégique est d'ores et déjà établie, mais les possibilités dépassent l'imagination. Il est indispensable de maîtriser cette évolution en étant lucide sur les risques potentiels. Mme la ministre déléguée Fleur Pellerin a récemment déclaré : « Si la sécurité des systèmes d'information n'est pas assurée, aucune économie moderne ne peut prospérer ». Cela nécessite de garantir la sécurité des données, de mettre en place des opérateurs de confiance et de promouvoir une approche de régulation, de préférence à une approche purement réglementaire.

M. le président Bruno Sido. Le secteur de la santé bénéficie, comme tous les autres secteurs, des progrès de la numérisation. L'audition du président de l'Académie des technologies nous a fait découvrir les perspectives intéressantes de la « domomédecine » pour les soins à domicile. Cependant, une défaillance des systèmes constituerait une menace directe pour la santé des personnes. Comment peut-on garantir, monsieur de la Boulaye, la sécurité des systèmes numériques oeuvrant dans ce secteur sensible ?

M. Olivier de la Boulaye, directeur du développement du secteur santé d'Altran. Je vous répondrai à travers une illustration : le projet PICADo, premier système opérationnel de domomédecine. Cela me permettra de vous présenter les solutions que nous pouvons, nous, les industriels, proposer pour sécuriser l'utilisation des données de santé.

Je rappelle que la domomédecine est un terme inventé par François Guinot, Président honoraire de l'Académie des Technologies, après la parution du rapport de cette Académie « Le patient, les technologies et la médecine ambulatoire » et repris à l'occasion de la journée Télésanté organisée Conseil Régional de Champagne-Ardenne le 4 novembre 2009. La domomédecine se définit comme l'ensemble des actes et soins, parfois complexes, dispensés au domicile du patient ou durant ses activités socio-professionnelles, au moins comparables en quantité et qualité à ceux effectués à l'hôpital voire de meilleure qualité, s'appuyant sur des technologies modernes. Elle vise à privilégier le maintien à domicile ou en activité et à stimuler le progrès médical.

C'est le cas par exemple de la chrono chimiothérapie, une des thérapies du projet PICADo. Le patient enverra à son médecin, via des capteurs communicants, des éléments tels que sa température ou son niveau d'activité, afin que celui-ci puisse adapter son traitement et proposer en temps réel le meilleur moment d'administration et les meilleurs dosages.

Ce type de dispositif doit évidemment respecter le cadre législatif et réglementaire existant, c'est-à-dire le décret du 19 octobre 2010 relatif à la télémédecine et la loi « informatique et libertés ». Les industriels que nous sommes doivent en outre tenir compte des préconisations du conseil de l'ordre des médecins et de celui des pharmaciens.

Selon l'article 34 de la loi « informatique et libertés », « le responsable du traitement [d'une donnée de santé] est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu'elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès. ». Le respect de cet article se décline selon cinq grands principes : la finalité des données ; leur pertinence - nous n'utilisons que celles dont nous avons réellement besoin - ; leur conservation pendant un temps limité - c'est le droit à l'oubli ; la sécurité et la confidentialité ; le respect des droits des personnes, qui nous impose, par exemple, de nous assurer que le patient accepte que ces données soient utilisées.

Le projet PICADo concerne quelques centaines de patients et associe à Altran des sociétés plus petites comme Axon, Voluntis, Bluelinea ou FSI, soit des partenaires aux parcours très différents, qui n'ont pas tous la même capacité à respecter les normes imposées par nos tutelles.

Un tel système de santé suppose trois niveaux de mise en place. Au niveau des processus, nous nous interrogeons sur la finalité ou l'usage. C'est la notion d'authentification, via , par exemple, la carte de professionnel de santé (CPS) ou la carte Vitale pour le patient. Nous cherchons ensuite comment collecter et utiliser ces informations, qui peuvent être utilisées à des fins, non seulement médicales, mais aussi médico-légales - d'où l'importance de mettre en place des systèmes garantissant une parfaite traçabilité. Deux nouveaux enjeux sont apparus récemment dans l'univers de l'e-santé : l'impact du sans-fil, qui, comme toute innovation, appelle de nouvelles solutions en termes de sécurité, et la problématique de la consommation énergétique.

Après les processus, notre réflexion porte sur les données. Nous bénéficions en la matière d'un cadre normatif assez précis, notamment en ce qui concerne l'hébergement des données de santé, soumis à l'agrément de l'Agence des systèmes d'information partagés de santé (ASIP). Cela suppose le respect d'un cahier des charges très précis en matière de redondance, de sécurisation et de traçabilité des données notamment.

Il faut enfin considérer le niveau applicatif, qui concerne la conception des logiciels, l'ergonomie ou la gestion des habilitations : beaucoup de failles de sécurité sont dues à des problèmes d'habilitation. Quant à la conception des logiciels, elle doit respecter un certain nombre de référentiels internationaux pour les systèmes d'information de santé, tel l' Integrating the Healthcare Enterprise , l'IHE. Ils nous permettent de respecter au mieux les très nombreuses normes en vigueur, qui sont en outre extrêmement complexes. Les seules directives européennes imposent à un projet tel que PICADo le respect de la norme ISO 13485, qui précise les exigences des systèmes de management de la qualité pour les dispositifs médicaux, de la norme ISO 62304, qui définit les exigences du cycle de vie des logiciels de dispositifs médicaux, et de la norme ISO 60601, qui fixe les exigences de développement d'un dispositif médical - pour ne parler que des plus importantes.

Je ne peux pas terminer mon propos sans évoquer deux notions. D'abord celle du « bring your own device ». Aujourd'hui, un médecin va plutôt utiliser son iPhone ou son iPad que son poste de travail pour transmettre des données, ce qui induit de nouveaux problèmes de sécurité des systèmes d'information de santé. La bonne nouvelle, c'est que nous avons des solutions pour y remédier.

L'autre notion est celle de modèle économique, qui appelle la capacité à proposer une itération et une progression dans la mise en place du niveau cible de conformité aux normes. En tant qu'industriel, nous souhaitons pouvoir à la fois conseiller un fabricant de dispositifs médicaux, qui est souvent une petite entreprise, et un professionnel de santé quant au bon niveau de risque.

M. le président Bruno Sido. Le dernier thème de cette table ronde va nous permettre de mettre en valeur la qualité remarquable de la recherche française dans le domaine du numérique, puisque c'est dans le cadre de l'Institut national de recherche en informatique et en automatique (Inria) qu'ont été mis au point les premiers dispositifs de vérification de la validité intrinsèque des programmes. Pourriez-vous, monsieur Gilles Dowek, nous expliquer de manière pédagogique les tenants et les aboutissants de ce problème scientifique complexe ?

M. Gilles Dowek, directeur scientifique adjoint à l'Institut national de recherche en informatique et en automatique (Inria). Les systèmes informatiques sont partout, pour le mieux en général. Ils permettent par exemple d'améliorer la qualité des soins médicaux, via notamment l'imagerie médicale ou la robotique chirurgicale ; ils facilitent l'accès à la connaissance, appelé à connaître une transformation radicale avec la mise en place d'e-universités. Ils ont bouleversé les modes de communications interpersonnelles. On ne peut pas, bien entendu, passer sous silence l'accroissement considérable de la productivité qu'on leur doit. C'est précisément parce que l'informatique nous apporte tous ces bénéfices que leur dysfonctionnement peut provoquer des dommages, tant matériels qu'humains, à la mesure de cette omniprésence.

On appelle domaines critiques ceux dans lesquels le dysfonctionnement d'un système informatique provoque des conséquences graves. On en compte au moins quatre : les transports, la santé, l'énergie - on a évoqué la sûreté des centrales nucléaires -, la banque et plus largement les services.

Définir les menaces pesant sur un système informatique suppose de faire la distinction traditionnelle entre sûreté et sécurité : c'est la différence entre défaillance involontaire et action malveillante. Un crash aérien, par exemple, peut être consécutif à une panne de son moteur : c'est là un problème de sûreté. Mais s'il est dû au déclenchement d'une bombe placée dans l'avion, il s'agit d'une faille de la sécurité.

Fabriquer des objets qui fonctionnent n'est certes pas un objectif propre à l'informatique. Cependant, les objets informatiques présentent la spécificité d'être les plus complexes de toute l'histoire de l'industrie humaine. Un programme compte plusieurs dizaines de millions de lignes, contre quelques dizaines de milliers dans un roman. C'est encore plus vrai s'agissant des matériels : il y a plusieurs milliards de transistors dans un processeur, contre cinq ou dix dans un poste de radio. Il est humainement impossible de construire un système aussi complexe sans se tromper. De plus, l'interconnexion des systèmes produit des bugs généralisés ou en cascade.

Étant donné le caractère faillible des êtres humains, le développement de logiciels ne peut pas être une activité exclusivement humaine. C'est la raison pour laquelle on utilise des outils informatiques pour concevoir des systèmes sans bugs. Ces outils s'appellent l'analyse statique, la vérification dans un modèle, la preuve, etc . Ils sont le fruit de recherches fondamentales en théorie de la démonstration, en théorie des langages de programmation et en combinatoire, ainsi que dans d'autres domaines à la frontière de l'informatique et des mathématiques. Ils ne sont pas plus interchangeables que ne le sont un marteau, un tournevis et une clé à molette : ils traitent des problèmes différents et doivent souvent être combinés. Ensemble, ils constituent une boite à outils qu'on appelle les méthodes formelles.

Ainsi, les algorithmes et les programmes de contrôle aérien peuvent être très complexes, mais la tâche qu'ils doivent réaliser est très simple : maintenir une distance de séparation minimale entre les avions à tout instant.

Lorsqu'on a cette spécification et ce programme, il est possible, en utilisant des outils appropriés, de démontrer, au sens mathématique du terme, que tel programme vérifie telle spécification.

La preuve de programme a été appliquée à de nombreux cas, notamment aux trains de la ligne 14 du métro parisien ou à certains compilateurs utilisés par Airbus.

En conclusion, la France fait partie des pays leaders en matière de recherche dans les méthodes formelles. Il y a, dans notre pays, un véritable potentiel de développement pour une industrie dans ce domaine.

Une manière de soutenir ce développement et d'améliorer la sûreté et la sécurité des logiciels que nous utilisons tous les jours est d'imposer, lors de la commande publique de systèmes critiques, l'utilisation de méthodes formelles, par exemple en utilisant le vocabulaire des critères communs, qui mesure la qualité d'un projet sur une échelle allant de EAL-1 à EAL-7. C'est déjà le cas, mais ce pourrait être systématique.

M. le président Bruno Sido. M. Bolignano va maintenant nous expliquer comment on peut tenter de développer, au niveau commercial, une activité de vérification de la sûreté intrinsèque des logiciels.

M. Dominique Bolignano, président directeur général de Prove&Run. Je vais vous parler de l'état actuel de l'utilisation des méthodes formelles dans l'industrie et du potentiel de celles-ci.

Pour ce faire, je répartirai les trois catégories de méthodes formelles dont a parlé Gilles Dowek en deux groupes.

Celles du premier groupe - analyse statique et vérification dans un modèle - sont les plus simples d'utilisation. Elles permettent de répondre à des questions précises, mais plus limitées, et d'éviter certains types d'erreurs informatiques ou sur certaines catégories de logiciels. Gérard Berry a donné plusieurs exemples de leur application dans les transports, notamment dans l'aéronautique. Ce sont, de loin, les plus utilisées dans l'industrie.

Une dizaine de sociétés - françaises ou contrôlées par de grands groupes français - commercialisent ces technologies. Malgré un grand potentiel de croissance, ces sociétés restent de taille modeste - entre 10 et 200 personnes. Elles n'en ont pas moins une grande importance pour la sûreté et la sécurité numériques.

Le deuxième groupe de méthodes formelles concerne la preuve de programme : il faut l'appliquer là où les techniques du premier groupe ne réussissent pas, car elle est beaucoup plus coûteuse et demande plus de temps. En revanche, son domaine d'application est beaucoup plus vaste. Elle couvre à peu près tous les secteurs qu'on a cités et permet de répondre à un nombre de questions beaucoup plus important.

Il en est ainsi pour la téléphonie mobile. La plupart des informations importantes, autant pour les entreprises que pour les particuliers, passent par les téléphones, et celles qui n'y passent pas sont accessibles à distance grâce à eux. C'est donc un point de vulnérabilité très important.

Actuellement, à chaque nouvelle version, quelques semaines suffisent pour que les téléphones de dernière génération - comme ceux d'Apple ou d'Android - soient crackés, c'est-à-dire attaqués et cassés dans leur sécurité. Les pirates ou les attaquants exploitent des vulnérabilités, qui sont des erreurs logicielles. Ce sont les bogues - ou bugs dont parlait Gérard Berry. Les bogues en matière de sûreté ont moins de répercussions, mais en matière de sécurité, quelques-uns suffisent pour mener une attaque de grande envergure. Voilà pourquoi on essaie de s'approcher le plus possible du « zéro faute ».

Ces erreurs sont exploitées pour des besoins relativement modestes, mais elles pourraient l'être pour lancer des attaques beaucoup plus graves. Cela nous renvoie aux propos qu'a tenus ce matin le représentant du ministère de la défense.

Je citerai deux exemples liés à la téléphonie mobile.

Le premier concerne les entreprises. La plupart des cadres utilisent leur téléphone à des fins aussi bien professionnelles que personnelles : ils consultent des mails et peuvent charger des applications à la fiabilité douteuse. Or les erreurs logicielles peuvent être utilisées pour corrompre et faire du cyberespionnage à relativement grande échelle, ce qui peut avoir des répercussions dramatiques sur l'entreprise.

Ces erreurs pourraient être évitées par une bonne application des méthodes formelles, en particulier de la preuve de programme. Certes, cela coûte cher et est difficile à faire, mais c'est faisable.

Deuxième axe : le paiement par téléphone. S'il y a eu beaucoup d'avancées grâce à la carte à puce, le téléphone reste un élément vulnérable dans la mesure où l'on a remplacé des terminaux de paiement relativement sécurisés par des objets qui le sont beaucoup moins.

Quant à la banque à domicile, qui n'est pas considérée comme un moyen de paiement mais permet de faire des virements, elle est encore plus vulnérable.

Il ne s'agit pas d'appliquer ces techniques sur tout le logiciel. En effet, les téléphones peuvent comporter jusqu'à plusieurs dizaines de millions de lignes de codes. Les architectures modernes permettent de se focaliser sur une « base de confiance », qui ne fait que quelques dizaines de milliers de lignes de codes : en s'attaquant à celles-ci, on peut vraiment s'approcher du « zéro défaut » s'agissant des parties critiques et éviter ces erreurs.

On a dit ce matin que cette problématique connaissait une croissance exponentielle. Je le confirme : nous n'en sommes qu'au début.

L'utilisation des méthodes formelles reste très modeste, essentiellement pour des problèmes liés à leur mise en oeuvre et au manque de disponibilité d'experts dans ces domaines. Cela étant, la nouvelle société que j'ai créée a pour objet de les appliquer à grande échelle : des raisons objectives m'amènent à penser que c'est possible.

Nous nous trouvons aujourd'hui dans une situation très proche de celle d'il y a trente ans, au moment de la conception en 3D. Des sociétés comme Dassault Systèmes, qui est devenu le numéro un mondial dans son domaine, ont transformé la manière dont le développement était fait . Aujourd'hui, l'enjeu est encore plus grand, car le potentiel est probablement beaucoup plus important.

Pour terminer, je rejoindrai Gilles Dowek en disant que c'est le moment de se lancer. Je le montre moi-même en investissant beaucoup. Les pouvoirs publics pourraient de leur côté favoriser l'utilisation de ces méthodes formelles, afin d'enclencher un cercle vertueux.

M. le président Bruno Sido. Je vous remercie. Le débat est ouvert.

Débat

M. Michel Cosnard, président directeur général de l'Inria. Ma question s'adresse à Dominique Bolignano : quel serait le bon modèle économique, susceptible de favoriser l'usage de méthodes de développement garantissant une meilleure qualité et une meilleure fiabilité des logiciels critiques ?

M. Dominique Bolignano. C'est un modèle que j'ai déjà testé dans de précédentes entreprises et que je compte appliquer à plus grande échelle. Il consiste à développer des composants réutilisables clés avec les méthodes formelles et à les licencier pour que, dans un deuxième temps, les clients utilisateurs demandent à se les approprier, licencient les outils et adoptent la technologie. Il faut entrer dans un cercle vertueux en démontrant que c'est faisable et utile, afin que les entreprises soient prêtes à investir.

M. Michel Cosnard. Y a-t-il un secteur d'activité privilégié ?

M. Dominique Bolignano. Oui. Nous allons commencer par le domaine de la téléphonie mobile, où il y a énormément à faire. Mais il y a aussi beaucoup à faire dans l'aéronautique, l'automobile et probablement aussi dans le domaine médical.

M. le président Bruno Sido. Monsieur le professeur, on nous a dit qu'il était humainement impossible, dans un programme de plusieurs milliers de lignes de code, de ne pas introduire quelque part une erreur, un bug. Mais ce bug, introduit involontairement par l'homme, se déclenchera-t-il de façon aléatoire ou systématique ?

M. Gérard Berry. Il est très difficile de vous répondre. Sur du hardware , sur un circuit, il y a des probabilités de panne qui sont chiffrées, raisonnables et mesurées. Sur un logiciel, la question n'a pas vraiment de sens. En effet, on peut ne jamais voir le bug qui existe. En général, il ne se produira pas, sauf si des hackers la cherchent. Car avec des bons hackers, la probabilité devient 1.

Ainsi, une faculté américaine a montré qu'on pouvait prendre le pouvoir sur 50 % des pacemakers livrés aux États-Unis : on peut les arrêter, envoyer 800 volts, faire absolument ce que l'on veut. Ce bug ne se produira jamais sur un humain normal, mais on peut le fabriquer exprès.

Il n'est donc pas ridicule de viser le « zéro défaut ». Cela demande de modifier le design. Il n'y a pas que la vérification, mais aussi la façon de concevoir les applications. Nous avons ainsi fabriqué des langages, dont la définition est mathématique et dont le mode d'emploi mélange formules mathématiques et commentaires en anglais.

Pour les bugs modernes, le danger réside donc essentiellement dans les hackers.

Mme Sylviane Toporkoff de l'Inria. Il existe maintenant des sociétés de hackers, qui sont très compétents. Fait-on systématiquement appel à elles lorsqu'on réalise un programme ?

M. Gérard Berry. Oui, cela arrive. D'assez nombreux hackers se sont fait embaucher, notamment par AT&T dans les télécoms.

Dans les sciences aussi, on fait de même. Après le bug d'Ariane, un grand informaticien, qui n'est pas du tout un hacker, a ainsi été employé pour analyser des programmes parce qu'il a une aptitude à découvrir des bugs là où les autres n'en trouvent pas.

Le problème est que ce n'est pas en se faisant embaucher par l'État français que les hackers gagnent le plus d'argent. Et donc, on n'a pas forcément les meilleurs ...

M. Olivier de la Boulaye. Aujourd'hui, c'est le client qui définit le prix. Nous aimerions avoir recours à l'ensemble des méthodologies qui pourraient améliorer la sûreté des logiciels. Mais les clients ne sont pas forcément disposés à faire appel à une société comme celle de M. Bolignano.

Il faudrait proposer une démarche itérative. L'important est de se donner une certaine durée pour avoir un cap et anticiper ce cap. Les méthodes qui sont proposées le permettent.

Nous nous intéressons aussi beaucoup à la « base de confiance », qui permet de travailler sur un socle que l'on peut ensuite étendre progressivement, et d'apporter une première réponse aux contraintes économiques que l'on rencontre dans ce genre de projets.

M. Jean-Yves Le Déaut. On nous a indiqué ce matin que l'informatique était une suite de couches successives de travaux qui continuaient à être utilisés et qu'il était impossible d'aller explorer la totalité des réalisations anciennes.

On nous a dit aussi qu'aujourd'hui, elle était faite de systèmes intégrés, de briques associées les unes aux autres. Êtes-vous capables de vérifier qu'il n'y a pas de problème entre les briques et d'empêcher des personnes malveillantes de s'introduire dans le système d'intégration ?

M. Dominique Bolignano. Il est en effet possible de passer entre les couches et d'aller en dessous des logiciels. Ces deux problèmes peuvent être évités en choisissant les bonnes architectures. Il ne suffit donc pas d'appliquer les méthodes formelles.

En matière de téléphonie mobile, nous avons ainsi réussi à convaincre les principaux fabricants de téléphones de modifier leur architecture, précisément pour aller mettre, sous les couches de logiciels, les parties que l'on pouvait véritablement sécuriser.

M. Gérard Berry. Attention : toute l'informatique n'est pas vieille ! Elle est même principalement récente. Il s'écrit beaucoup plus de programmes maintenant qu'il ne s'en est jamais écrit. Mais les problèmes liés à la vie des appareils se posent effectivement parce qu'à l'époque, on ne se préoccupait pas de cela.

Il faut absolument fabriquer des composants de très haute qualité. D'où l'importance des procédures et des contraintes de certification. En avionique, il y a ainsi des procédures de certification internationales obligatoires et des réciprocités entre les pays. En revanche, dans le nucléaire, il n'y a que des procédures de certification nationales, nettement plus indicatives et variables selon les pays. Au Japon, par exemple, certaines normes valables dans les années cinquante sont restées les mêmes.

La qualité des règles imposées par les États est absolument essentielle. Or en matière de santé, notamment, les normes ne sont pas tout à fait définies.

M. Olivier de la Boulaye. On voit bien à cet égard que les niveaux d'exigence ne sont pas les mêmes pour un dépistage et la prise en charge d'un acte médical.

M. Gilles Dowek. Il est beaucoup plus facile de développer des produits de qualité en utilisant des méthodes formelles au moment où on les développe, que de revenir sur des vieux codes d'il y a dix ou vingt ans, ou même de vieux algorithmes. En contrôle aérien, on m'avait demandé de démontrer la correction d'un algorithme ; je n'ai pas réussi et j'ai proposé mon propre algorithme. C'est de cette manière que l'on peut faire avancer les choses : davantage par une « co-conception » - conception de l'objet et de sa preuve en même temps - que par un retour sur le passé.

Ensuite, il ne suffit pas que les composants qui sont assemblés soient sûrs pour que l'ensemble le soit aussi. Mais les méthodes formelles peuvent s'appliquer aussi bien pour démontrer la sûreté de composants que celle de l'assemblage. Si cette dernière constitue un problème plus difficile, l'objectif est bien la sûreté globale, qui n'est jamais que celle du maillon le plus faible.

M. Michel Cosnard. Gilles Dowek a évoqué les critères EAL de 1 à 7. J'aimerais qu'il les précise et nous donne quelques exemples et, éventuellement, des recommandations sur leur utilisation. Y a-t-il des cas où un niveau minimum d'exigence serait souhaitable ? Si oui, comment le traduire en obligation réglementaire ?

M. Gilles Dowek. Je reviens sur une autre question que vous avez posée tout à l'heure, relative à la probabilité qu'un bug se produise.

Prenons l'exemple du bug du Pentium, évoqué par Gérard Berry. Nous sommes face à un circuit qui fait des multiplications. Si on essaie de multiplier 3 par 4, cela fait 12 ; en revanche, si on multiplie 0 par 0 - et c'est là qu'il y a un bug - cela fait 256. S'interroger sur la probabilité que ce bug se produise revient à s'interroger sur celle que l'utilisateur de la calculette décide de faire cette multiplication de 0 par 0.

Cela nous amène à la première méthode, que personne n'a mentionnée, consistant, pour vérifier que des programmes sont corrects, à les tester, et donc à les utiliser. On fait une, puis trois, puis dix multiplications. Si le résultat est exact pour dix opérations, on se dit que le programme ou le circuit semble correct, et l'on s'arrête là. Cela définit les niveaux EAL les plus bas, soit 1 ou 2.

Il y a ensuite, au milieu de la gamme, d'autres critères. On demande au développeur d'exprimer formellement, sans établir de preuve, mais de manière très précise et mathématique, la spécification du programme.

Ce n'est qu'aux niveaux 6 et 7, les plus élevés, que l'on demande au développeur, non seulement d'exprimer ainsi ce que doit faire le programme, mais aussi de démontrer qu'il fait bien ce que l'on attend de lui.

Ces critères correspondent à des niveaux d'exigence et de coût variables. Pour certaines applications, le bug n'est pas très grave : c'est le cas par exemple pour un DVD, au contraire d'un avion de ligne. Mais parfois il se mesure en milliards de dollars. Or pour anticiper un bug d'un milliard de dollars, on peut s'offrir beaucoup de méthodes formelles ...

M. Jean-Yves Marion, responsable du Laboratoire de haute sécurité en informatique de Nancy. La sûreté informatique, le fait que les programmes n'aient pas de bugs, est importante. Mais la sécurité ne se réduit pas à cela. On peut attaquer un programme quasiment sans bug en utilisant l'ingénierie sociale, c'est-à-dire en contournant les problèmes d'usage au niveau des utilisateurs. D'où l'intérêt des systèmes de protection tels que les pare-feu, les antivirus ou les systèmes de virtualisation.

M. Marko Erman. Je suis d'accord avec vous. La sécurité n'est pas une caractéristique purement technique. Elle se conçoit au niveau d'un système.

Nous faisons des audits de cybersécurité, soit en anticipation à la demande des entreprises, soit en post attack . Comme dans les accidents d'avion, le facteur humain est souvent celui qui fait casser le système. Dans un système informatique totalement fermé, un immeuble blindé, si les personnels introduisent des clés USB non contrôlées, cela peut être catastrophique.

Au-delà de la sécurité technique, il faut s'intéresser à la sécurité physique, aux protocoles, aux process, à l'organisation et à la formation - via une sorte de labellisation ou de certification des personnes. De fait, lorsque la technologie est tellement diffusée, que toute personne est dans le système, la situation devient très difficile.

On progressera dans la sécurité quand le plus grand nombre des citoyens sera conscient des risques. Il ne s'agit pas de devenir paranoïaque, mais c'est en connaissant les risques que l'on peut se comporter correctement et s'en protéger.

M. Jean-Yves Le Déaut. Lorsque je demande à mes étudiants de Sciences Po de situer le bug informatique sur une échelle des risques, ils le classent en dernier ! Je pense que le citoyen n'a pas pris conscience de l'existence du risque informatique.

Les bienfaits de l'informatique sont avérés, mais nous devons nous prémunir contre les risques qu'elle entraîne et les attaques. L'objectif de cette table ronde est aussi de savoir s'il faut faire évoluer la législation ou mettre en place une régulation dans ce domaine.

M. Gilles Dowek. C'est précisément parce que les bienfaits de l'informatique sont nombreux que les risques existent.

M. Gérard Berry. À l'heure actuelle, les gens peuvent passer de l'absence totale d'inquiétude à l'angoisse. Ces deux attitudes absurdes prouvent qu'ils ignorent totalement ce qu'est l'informatique. Or la seule façon de maîtriser un risque, ou un bienfait, c'est d'en comprendre la nature. Il est sûr qu'un travail de fond s'impose dans ce domaine. L'éducation a un rôle essentiel à jouer à cet égard.

M. le président Bruno Sido. Vous avez parfaitement raison. Cela étant, les gens supportent de moins en moins les contrariétés - que les trains arrivent ou partent en retard, ou que les téléphones ne fonctionnent plus. Après tout, la panne d'Orange n'était pas particulièrement gênante, même si on n'a pas pu téléphoner pendant plusieurs heures.

M. Jean-Yves Le Déaut. Monsieur Berry, je vous rejoins sur le fait que les gens passent de la négation du risque à sa surestimation et sur l'ignorance en informatique. Si les sujets que l'Office étudie en amont de la législation sont ceux qui font débat dans la société - OGM, ondes électromagnétiques, réchauffement climatique, vaccins, nucléaire... -, il arrive que certains ne donnent pas lieu à débat. C'est ce qui est arrivé avec les OGM : en 1991, la transposition d'une directive européenne était passée dans l'indifférence générale. Il a fallu attendre cinq ans, soit les exportations de soja américain, pour que les OGM deviennent un problème politique. Avec les nanotechnologies, nous avons connu à peu près le même phénomène.

Si l'on aborde un sujet très tôt, cela n'intéresse absolument personne, et si on le fait trop tard, on nous prête l'intention de vouloir justifier certaines positions. Ces sujets sont très compliqués : il est difficile de se prononcer en amont des évolutions techniques et de comprendre l'incidence qu'elles auront sur la société.

M. Claude Kirchner. Je voudrais revenir sur la panne de France Télécom. Certes, il était très inconfortable de ne pas pouvoir téléphoner pendant onze heures. Mais cette panne a eu des conséquences plus larges qu'on n'avait pas envisagées : des sociétés importantes, qui faisaient passer leur cellule de gestion de crise par la téléphonie mobile, ont arrêté complètement leur activité lorsqu'elles se sont rendu compte qu'elles n'étaient plus capables de gérer une éventuelle crise.

Il ne faut pas oublier le rôle essentiel que joue la maintenance. Un logiciel a une vie et peut connaître, au cours de cette vie, des phases critiques - je pense plus particulièrement aux mises à jour. Comment ce problème est-il géré ? L'est-il de façon sûre ?

M. Gérard Berry. Ce problème a beaucoup évolué ces derniers temps. Par exemple, ceux qui possèdent un ordinateur reçoivent des nouvelles versions de logiciel - notamment du logiciel Java, qui, en ce moment, fait l'objet de nombreuses attaques. Avant, ce n'était pas le cas.

Mais ce qui vaut pour les ordinateurs est beaucoup plus compliqué pour les voitures. Je connais quelqu'un qui a acheté une voiture très moderne. Sous le capot de celle-ci, il y a des emplacements pour l'eau, l'huile, le lave-glace ... et pour télécharger des logiciels. Or les garagistes sont très démunis devant les pannes logicielles. Dans cet exemple, le malheureux automobiliste est resté bloqué dans sa voiture ! Il faut combattre l'excès de maintenance. S'il s'agit de rajouter des fonctionnalités, pourquoi pas ? Mais si cela doit conduire à rajouter des bugs, c'est très dangereux.

M. Gilles Dowek. Une panne de téléphone risque de ne pas être bénigne. Le téléphone peut servir à appeler les pompiers. Au moment de la panne d'Orange, un seul réseau était affecté et on imagine qu'il aurait été possible, en cas d'incendie, de passer par un autre opérateur. Mais prenez le cas d'une personne attachée à la sûreté d'une centrale nucléaire qui utilise son téléphone lorsqu'elle est d'astreinte. Si un incident nucléaire intervient au même moment, il peut se produire des bugs en cascade, avec des conséquences tout à fait dramatiques.

M. Marko Erman. La société a évolué. Les réseaux de données nous offrent aujourd'hui des possibilités que nous n'avions pas par le passé, comme l'approvisionnement des grandes cités. La société devient donc extrêmement dépendante de leur bon fonctionnement.

Je suis d'accord pour dire que la panne d'un réseau de téléphonie ne peut être résumée à l'impossibilité de quelques personnes de communiquer. Elle peut aussi provoquer un « arrêt » de la société.

M. le président Bruno Sido. Cela relève d'une autre table ronde. Lorsqu'on a vraiment besoin de quelque chose, on doit avoir des systèmes redondants. Surveiller une centrale nucléaire avec un téléphone portable, ce n'est pas raisonnable ! Reste que le sujet est grave. C'est bien pourquoi, ce matin, j'ai parlé de « fragilisation ».

M. Gilles Dowek. Il n'y a qu'un seul réseau Internet. Celui-ci ne peut donc faire l'objet d'un système redondant.

Mme Nathalie Le Bars, du CEA. J'ai toujours un pincement au coeur quand on laisse croire que la sécurité nucléaire pourrait passer par un portable !

Mme Hélène Legras, correspondant « informatique et libertés » à la direction juridique d'Areva. En tant que salariée d'Areva, je confirme qu'on ne peut prendre un tel risque !

Les thèmes associés à ce dossier

Page mise à jour le

Partager cette page