La dépendance des États aux géants du numérique pose-t-elle problème ? 

La récente panne cri­tique sur les serveurs Win­dows, liée à l’EDR Fal­con de Crowd­Strike¹, a remis en per­spec­tive les risques liés à la dépen­dance des ser­vices de l’État aux logi­ciels privés. Si le min­istre des Armées s’est voulu ras­sur­ant², il n’en demeure pas moins que l’utilisation au sein de l’État de ser­vices numériques com­mer­ci­aux doit relever d’une analyse béné­fice-risque visant à s’assurer que le gain d’efficacité dépasse les con­ces­sions en ter­mes de souveraineté.

La sou­veraineté d’un État est la capac­ité de celui-ci à garan­tir son indépen­dance vis-à-vis d’autres États. Elle requiert la fac­ulté de dis­pos­er des ressources humaines, matérielles, tech­nologiques ain­si que de toute autre com­posante néces­saire pour pro­duire les biens et les ser­vices vitaux de la nation. 

Cette capac­ité se juge soit au niveau sys­témique, soit au niveau de chaque poli­tique publique. En effet, la sou­veraineté con­cerne les aspects ali­men­taires, financiers, mil­i­taires et désor­mais le numérique – qui est une dimen­sion com­mune et trans­verse à cha­cun de ces domaines.

La sou­veraineté numérique con­cerne de nom­breux aspects, dont les prin­ci­paux sont³,⁴ :

• Les biens numériques, puisqu’il est néces­saire de dis­pos­er de matériels de base générés sans risque de sécu­rité (fibres, antennes, serveurs, pare-feu, rou­teurs…) pour con­stru­ire un sys­tème d’information de confiance.

• Les ser­vices numériques, car il est indis­pens­able d’être capa­ble de col­lecter, traiter et restituer l’information de manière sécurisée pour assur­er les fonc­tions régali­ennes de l’État (iden­tité numérique, ges­tion de crise, col­lecte des impôts et des coti­sa­tions sociales…).

L’utilisation de solu­tions non-éta­tiques per­met d’accélérer la mise à dis­po­si­tion de solu­tions déjà dévelop­pées par ailleurs, ce qui per­met de con­cen­tr­er l’effort numérique de l’État sur son cœur de méti­er. Cela répond sou­vent à une logique d’efficacité et d’économie d’échelle, puisqu’une solu­tion pro­prié­taire ou open source est par­fois util­isée par des mil­liers ou mil­lions d’autres organ­i­sa­tions. Nous pou­vons citer les édi­teurs de texte ou de cal­cul (dif­férentes suites Office), les logi­ciels de ges­tion de paye ou de con­gés (SAP, HR-Access…)⁵ ou les logi­ciels d’envoi et de récep­tion d’e‑mails (Out­look, Thun­der­bird…). Ces logi­ciels trans­vers­es sont éprou­vés et prêts à l’utilisation. La créa­tion d’une solu­tion interne à l’administration serait très coû­teuse et prob­a­ble­ment inadap­tée à la ges­tion d’un besoin com­mun du numérique.

L’acquisition de matériel via des presta­tions per­met par ailleurs de répon­dre à des besoins qui néces­sit­eraient des investisse­ments très impor­tants pour l’administration. Et ce, sans qu’elle puisse en assur­er facile­ment des débouchés économiques. C’est notam­ment le cas pour l’achat d’ordinateurs, d’imprimantes, de baies de stock­age ou de matériel réseau. Ces acqui­si­tions offrent une garantie d’expertise et de savoir-faire sur des com­posants rel­a­tive­ment stan­dards ain­si que la pos­si­bil­ité de recours à une assis­tance numérique dédiée. Cette approche offre une excel­lente effi­cac­ité pour autant que les matériels util­isés soient suff­isam­ment stan­dard­is­és pour s’intégrer dans le sys­tème d’information de l’administration et puis­sent être com­plétés par des ser­vices sup­plé­men­taires : appli­ca­tions, super­vi­sion, détec­tion d’intrusion, etc.

L’utilisation de solu­tions open source peut, par ailleurs, offrir des capac­ités d’innovation et de réac­tiv­ité impor­tantes, puisqu’elle per­met d’intégrer des out­ils et appli­ca­tions rapi­de­ment avec un coût d’investissement mod­éré. D’autre part, cette approche per­met d’attirer des pro­fils numériques soucieux de con­tribuer à la com­mu­nauté open source et d’offrir aux citoyens une réelle trans­parence sur les out­ils util­isés au sein de l’administration⁶.

Les solu­tions numériques pro­posées par les sociétés com­mer­ciales répon­dent à la régle­men­ta­tion européenne et française. Mais elles doivent par­fois se con­former à des régle­men­ta­tions étrangères qui dif­fèrent par exem­ple sur des sujets de pro­tec­tion des intérêts nationaux. Pour illus­tr­er ce risque, nous pou­vons citer le Patri­ot Act, créé après les atten­tats ter­ror­istes de 2001, qui per­met au FBI de con­train­dre des entre­pris­es à lui don­ner accès à leurs bases de don­nées per­son­nelles, même pour les infor­ma­tions stock­ées en Europe. De manière ana­logue, le Cloud Act per­met aux autorités améri­caines d’ac­céder aux don­nées stock­ées par des entre­pris­es améri­caines, même si ces don­nées sont stock­ées en Europe con­traire­ment aux oblig­a­tions du RGPD⁷.

Par ailleurs, les solu­tions com­mer­ciales ou open source peu­vent présen­ter des vul­néra­bil­ités dont la cor­rec­tion peut être dif­férée à cause des coûts, du manque de ressources humaines ou pour toute autre rai­son. Ces retards dans le main­tien en con­di­tions de sécu­rité ne sont pas sys­té­ma­tique­ment con­nus de la société ou ne font pas l’objet d’une infor­ma­tion immé­di­ate des clients. Ain­si, ces solu­tions non-dévelop­pées par l’État peu­vent créer des failles de sécu­rité sans que les ser­vices éta­tiques n’en soient néces­saire­ment con­scients. La faille liée à l’utilisation du logi­ciel de trans­fert MOVEit a impacté en pro­fondeur le pro­gramme Med­ic­aid du Col­orado⁸.

De plus, l’u­til­i­sa­tion crois­sante de solu­tions numériques dévelop­pées par des sociétés privées peut accroître la dépen­dance de l’État vis-à-vis des tech­nolo­gies privées. Cela peut don­ner aux entre­pris­es privées un pou­voir impor­tant sur le fonc­tion­nement de l’État et peut lim­iter sa capac­ité à maîtris­er ses coûts et ser­vices. Le change­ment impor­tant de poli­tique tar­i­faire con­cer­nant les solu­tions VMware est un exem­ple qui peut illus­tr­er cette dimen­sion⁹.

Enfin, les proces­sus d’intégration des solu­tions non-éta­tiques au sein des sys­tèmes d’information de l’État néces­si­tent une ges­tion par­ti­c­ulière­ment rigoureuse des inter­faces entre les dif­férents com­posants, qu’ils soient logi­ciels et/ou matériels. En ce sens, les pro­to­coles d’interopérabilité doivent être pré­cisé­ment défi­nis et con­formes aux régle­men­ta­tions et aux stan­dards de sécu­rité les plus récents, afin d’éviter les poten­tielles vul­néra­bil­ités exploita­bles. Un exem­ple symp­to­ma­tique : l’u­til­i­sa­tion d’API REST­ful dans le cadre de com­mu­ni­ca­tions inter­ser­vices. Elle peut per­me­t­tre une inté­gra­tion flu­ide et offre une couche de sécu­rité via des pro­to­coles d’authentification et de chiffre­ment. Par ailleurs, l’adop­tion de solu­tions de con­teneuri­sa­tion comme Kuber­netes ou Dock­er est à con­sid­ér­er avec atten­tion. La con­teneuri­sa­tion per­met, en effet, une ges­tion qui est plus agile et plus sécurisée lors des déploiements d’ap­pli­ca­tions¹⁰.

Pour opti­miser le fonc­tion­nement de l’État, nous pen­sons qu’il est impor­tant de rechercher un équili­bre entre les aspects de sou­veraineté et d’efficacité. Ain­si, nous pro­posons plusieurs ori­en­ta­tions non-exhaustives :

1. Définir les ser­vices pou­vant être exter­nal­isés et ceux devant absol­u­ment être réal­isés en interne. Cette approche con­cerne les appli­ca­tions métiers (cal­cul de l’impôt pour la DGFiP, appli­ca­tions de sécu­rité intérieure pour les forces de l’ordre…), ain­si que les ser­vices tech­niques néces­saires (bureau­tique, nav­i­ga­tion inter­net, sys­tème d’exploitation, fonc­tion­nement du réseau…).

2. Iden­ti­fi­er les risques liés à l’externalisation et les mesures de mit­i­ga­tion. L’objectif est de définir les actions à réalis­er pour con­serv­er au sein de l’État la maîtrise de chaque ser­vice exter­nal­isé. Pour cela, il est recom­mandé de définir les modal­ités d’organisation de l’externalisation : acteurs impliqués, engage­ments con­tractuels, procé­dures de véri­fi­ca­tion, capac­ité à engager une réversibil­ité… Ces actions s’inscrivent dans les proces­sus d’intégration de la sécu­rité dans les pro­jets et leur val­i­da­tion lors de la démarche d’homologation de sécu­rité¹¹.

3. Porter une atten­tion par­ti­c­ulière aux procé­dures de MCO/MCS. Cette tâche vise à garan­tir que les solu­tions internes et externes sont mis­es à jour régulière­ment, en vue de cor­riger les dys­fonc­tion­nements et les failles de sécu­rité. En effet, le plus vite les patchs sont réal­isés, le plus rapi­de­ment les appli­ca­tions sont pro­tégées con­tre les failles et les dys­fonc­tion­nements con­nus. Cette approche per­met de sécuris­er le main­tien des solu­tions util­isées à l’état de l’art.

4. S’appuyer sur une approche DevSec­Ops. Au cœur d’une démarche inté­grée néces­saire, l’adoption d’une approche DevSec­Ops est un moyen qui per­me­t­tra de ren­forcer la sécu­rité au moment des pre­mières phas­es du développe­ment du logi­ciel. C’est en inté­grant des tests de sécu­rité automa­tisés et robustes dans les pipelines CI/CD (Con­tin­u­ous Inte­gra­tion/Con­tin­u­ous Deploy­ment) que les prin­ci­pales vul­néra­bil­ités peu­vent être détec­tées et cor­rigées. C’est par­ti­c­ulière­ment effi­cace, car cela per­met d’avoir une cor­rec­tion avant que le code n’atteigne l’environnement de pro­duc­tion. Cette approche peut être à l’origine de dif­férences sub­stantielles pour les appli­ca­tions cri­tiques de l’État. Pour ces types d’application, une faille de sécu­rité peut avoir des con­séquences directes au niveau même de la sou­veraineté numérique¹².

5. Sen­si­bilis­er l’ensemble des acteurs et met­tre en place une comi­tolo­gie dédiée. Cette action vise à s’assurer que chaque agent de l’organisation dis­pose des con­nais­sances con­cer­nant le fonc­tion­nement de l’application et la prise en compte des cor­rec­tifs remon­tés par les CERT¹³. Ain­si, la pro­tec­tion de l’application sera mieux prise en compte et per­me­t­tra de pri­oris­er les évo­lu­tions les plus sen­si­bles pour l’État.  

6. S’appuyer sur un sys­tème de sur­veil­lance et pour la détec­tion d’in­tru­sions. Les SIEM (Secu­ri­ty Infor­ma­tion and Event Man­age­ment) sont une autre dimen­sion tech­nique essen­tielle lors de la mise en place de sys­tèmes robustes. En effet, les solu­tions SIEM telles que ELK Stack ou Splunk sont déter­mi­nantes pour pou­voir effectuer l’analyse des logs dans une con­fig­u­ra­tion en temps réel, afin de détecter de manière effi­cace des com­porte­ments et des pat­terns anor­maux qui peu­vent révéler des failles de sécu­rité. Cette inté­gra­tion d’outils qui pos­sè­dent des sys­tèmes de réponse automa­tisée peut per­me­t­tre la réduc­tion du temps de réac­tion face à une men­ace. C’est un aspect déter­mi­nant pour lim­iter les poten­tiels impacts au niveau des infra­struc­tures cri­tiques de l’État¹⁴.