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

La récente panne cri­tique sur les ser­veurs Win­dows, liée à l’EDR Fal­con de Crowd­Strike¹, a remis en pers­pec­tive les risques liés à la dépen­dance des ser­vices de l’État aux logi­ciels pri­vés. Si le ministre des Armées s’est vou­lu ras­su­rant², il n’en demeure pas moins que l’utilisation au sein de l’État de ser­vices numé­riques com­mer­ciaux doit rele­ver d’une ana­lyse béné­fice-risque visant à s’assurer que le gain d’efficacité dépasse les conces­sions en termes de souveraineté.

La sou­ve­rai­ne­té d’un État est la capa­ci­té de celui-ci à garan­tir son indé­pen­dance vis-à-vis d’autres États. Elle requiert la facul­té de dis­po­ser des res­sources humaines, maté­rielles, tech­no­lo­giques ain­si que de toute autre com­po­sante néces­saire pour pro­duire les biens et les ser­vices vitaux de la nation. 

Cette capa­ci­té se juge soit au niveau sys­té­mique, soit au niveau de chaque poli­tique publique. En effet, la sou­ve­rai­ne­té concerne les aspects ali­men­taires, finan­ciers, mili­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­ve­rai­ne­té numé­rique concerne de nom­breux aspects, dont les prin­ci­paux sont³,⁴ :

• Les biens numé­riques, puisqu’il est néces­saire de dis­po­ser de maté­riels de base géné­rés sans risque de sécu­ri­té (fibres, antennes, ser­veurs, pare-feu, rou­teurs…) pour construire un sys­tème d’information de confiance.

• Les ser­vices numé­riques, car il est indis­pen­sable d’être capable de col­lec­ter, trai­ter et res­ti­tuer l’information de manière sécu­ri­sée pour assu­rer les fonc­tions réga­liennes de l’État (iden­ti­té 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éve­lop­pées par ailleurs, ce qui per­met de concen­trer l’effort numé­rique de l’État sur son cœur de métier. 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 uti­li­sée par des mil­liers ou mil­lions d’autres orga­ni­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 congé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­verses 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 pro­ba­ble­ment inadap­tée à la ges­tion d’un besoin com­mun du numérique.

L’acquisition de maté­riel via des pres­ta­tions per­met par ailleurs de répondre à des besoins qui néces­si­te­raient des inves­tis­se­ments très impor­tants pour l’administration. Et ce, sans qu’elle puisse en assu­rer faci­le­ment des débou­chés éco­no­miques. C’est notam­ment le cas pour l’achat d’ordinateurs, d’imprimantes, de baies de sto­ckage ou de maté­riel réseau. Ces acqui­si­tions offrent une garan­tie d’expertise et de savoir-faire sur des com­po­sants rela­ti­ve­ment stan­dards ain­si que la pos­si­bi­li­té de recours à une assis­tance numé­rique dédiée. Cette approche offre une excel­lente effi­ca­ci­té pour autant que les maté­riels uti­li­sés soient suf­fi­sam­ment stan­dar­di­sés pour s’intégrer dans le sys­tème d’information de l’administration et puissent ê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 capa­ci­tés d’innovation et de réac­ti­vi­té impor­tantes, puisqu’elle per­met d’intégrer des outils 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 sou­cieux de contri­buer à la com­mu­nau­té open source et d’offrir aux citoyens une réelle trans­pa­rence sur les outils uti­li­sés au sein de l’administration⁶.

Les solu­tions numé­riques pro­po­sées par les socié­tés com­mer­ciales répondent à la régle­men­ta­tion euro­péenne et fran­çaise. Mais elles doivent par­fois se confor­mer à des régle­men­ta­tions étran­gères qui dif­fèrent par exemple sur des sujets de pro­tec­tion des inté­rêts natio­naux. Pour illus­trer ce risque, nous pou­vons citer le Patriot Act, créé après les atten­tats ter­ro­ristes de 2001, qui per­met au FBI de contraindre des entre­prises à lui don­ner accès à leurs bases de don­nées per­son­nelles, même pour les infor­ma­tions sto­ckées en Europe. De manière ana­logue, le Cloud Act per­met aux auto­ri­tés amé­ri­caines d’ac­cé­der aux don­nées sto­ckées par des entre­prises amé­ri­caines, même si ces don­nées sont sto­ckées en Europe contrai­re­ment aux obli­ga­tions du RGPD⁷.

Par ailleurs, les solu­tions com­mer­ciales ou open source peuvent pré­sen­ter des vul­né­ra­bi­li­tés dont la cor­rec­tion peut être dif­fé­rée à cause des coûts, du manque de res­sources humaines ou pour toute autre rai­son. Ces retards dans le main­tien en condi­tions de sécu­ri­té ne sont pas sys­té­ma­ti­que­ment connus de la socié­té ou ne font pas l’objet d’une infor­ma­tion immé­diate des clients. Ain­si, ces solu­tions non-déve­lop­pées par l’État peuvent créer des failles de sécu­ri­té sans que les ser­vices éta­tiques n’en soient néces­sai­re­ment conscients. La faille liée à l’utilisation du logi­ciel de trans­fert MOVEit a impac­té en pro­fon­deur le pro­gramme Medi­caid du Colo­ra­do⁸.

De plus, l’u­ti­li­sa­tion crois­sante de solu­tions numé­riques déve­lop­pées par des socié­tés pri­vées peut accroître la dépen­dance de l’État vis-à-vis des tech­no­lo­gies pri­vées. Cela peut don­ner aux entre­prises pri­vées un pou­voir impor­tant sur le fonc­tion­ne­ment de l’État et peut limi­ter sa capa­ci­té à maî­tri­ser ses coûts et ser­vices. Le chan­ge­ment impor­tant de poli­tique tari­faire concer­nant les solu­tions VMware est un exemple qui peut illus­trer cette dimen­sion⁹.

Enfin, les pro­ces­sus d’intégration des solu­tions non-éta­tiques au sein des sys­tèmes d’information de l’État néces­sitent une ges­tion par­ti­cu­liè­re­ment rigou­reuse des inter­faces entre les dif­fé­rents com­po­sants, qu’ils soient logi­ciels et/ou maté­riels. En ce sens, les pro­to­coles d’interopérabilité doivent être pré­ci­sé­ment défi­nis et conformes aux régle­men­ta­tions et aux stan­dards de sécu­ri­té les plus récents, afin d’éviter les poten­tielles vul­né­ra­bi­li­tés exploi­tables. Un exemple symp­to­ma­tique : l’u­ti­li­sa­tion d’A­PI RES­T­ful dans le cadre de com­mu­ni­ca­tions inter­ser­vices. Elle peut per­mettre une inté­gra­tion fluide et offre une couche de sécu­ri­té via des pro­to­coles d’authentification et de chif­fre­ment. Par ailleurs, l’a­dop­tion de solu­tions de conte­neu­ri­sa­tion comme Kuber­netes ou Docker est à consi­dé­rer avec atten­tion. La conte­neu­ri­sa­tion per­met, en effet, une ges­tion qui est plus agile et plus sécu­ri­sée lors des déploie­ments d’ap­pli­ca­tions¹⁰.

Pour opti­mi­ser le fonc­tion­ne­ment de l’État, nous pen­sons qu’il est impor­tant de recher­cher un équi­libre entre les aspects de sou­ve­rai­ne­té et d’efficacité. Ain­si, nous pro­po­sons plu­sieurs orien­ta­tions non-exhaustives :

1. Défi­nir les ser­vices pou­vant être exter­na­li­sés et ceux devant abso­lu­ment être réa­li­sés en interne. Cette approche concerne les appli­ca­tions métiers (cal­cul de l’impôt pour la DGFiP, appli­ca­tions de sécu­ri­té inté­rieure pour les forces de l’ordre…), ain­si que les ser­vices tech­niques néces­saires (bureau­tique, navi­ga­tion inter­net, sys­tème d’exploitation, fonc­tion­ne­ment du réseau…).

2. Iden­ti­fier les risques liés à l’externalisation et les mesures de miti­ga­tion. L’objectif est de défi­nir les actions à réa­li­ser pour conser­ver au sein de l’État la maî­trise de chaque ser­vice exter­na­li­sé. Pour cela, il est recom­man­dé de défi­nir les moda­li­tés d’organisation de l’externalisation : acteurs impli­qués, enga­ge­ments contrac­tuels, pro­cé­dures de véri­fi­ca­tion, capa­ci­té à enga­ger une réver­si­bi­li­té… Ces actions s’inscrivent dans les pro­ces­sus d’intégration de la sécu­ri­té dans les pro­jets et leur vali­da­tion lors de la démarche d’homologation de sécu­ri­té¹¹.

3. Por­ter une atten­tion par­ti­cu­lière aux pro­cé­dures de MCO/MCS. Cette tâche vise à garan­tir que les solu­tions internes et externes sont mises à jour régu­liè­re­ment, en vue de cor­ri­ger les dys­fonc­tion­ne­ments et les failles de sécu­ri­té. En effet, le plus vite les patchs sont réa­li­sés, le plus rapi­de­ment les appli­ca­tions sont pro­té­gées contre les failles et les dys­fonc­tion­ne­ments connus. Cette approche per­met de sécu­ri­ser le main­tien des solu­tions uti­li­sées à l’état de l’art.

4. S’appuyer sur une approche Dev­Se­cOps. Au cœur d’une démarche inté­grée néces­saire, l’adoption d’une approche Dev­Se­cOps est un moyen qui per­met­tra de ren­for­cer la sécu­ri­té au moment des pre­mières phases du déve­lop­pe­ment du logi­ciel. C’est en inté­grant des tests de sécu­ri­té auto­ma­ti­sés et robustes dans les pipe­lines CI/CD (Conti­nuous Inte­gra­tion/Conti­nuous Deploy­ment) que les prin­ci­pales vul­né­ra­bi­li­tés peuvent être détec­tées et cor­ri­gées. C’est par­ti­cu­liè­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­stan­tielles pour les appli­ca­tions cri­tiques de l’État. Pour ces types d’application, une faille de sécu­ri­té peut avoir des consé­quences directes au niveau même de la sou­ve­rai­ne­té numé­rique¹².

5. Sen­si­bi­li­ser l’ensemble des acteurs et mettre en place une comi­to­lo­gie dédiée. Cette action vise à s’assurer que chaque agent de l’organisation dis­pose des connais­sances concer­nant le fonc­tion­ne­ment 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­met­tra de prio­ri­ser les évo­lu­tions les plus sen­sibles pour l’État.  

6. S’appuyer sur un sys­tème de sur­veillance et pour la détec­tion d’in­tru­sions. Les SIEM (Secu­ri­ty Infor­ma­tion and Event Mana­ge­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 effec­tuer l’analyse des logs dans une confi­gu­ra­tion en temps réel, afin de détec­ter de manière effi­cace des com­por­te­ments et des pat­terns anor­maux qui peuvent révé­ler des failles de sécu­ri­té. Cette inté­gra­tion d’outils qui pos­sèdent des sys­tèmes de réponse auto­ma­ti­sée peut per­mettre la réduc­tion du temps de réac­tion face à une menace. C’est un aspect déter­mi­nant pour limi­ter les poten­tiels impacts au niveau des infra­struc­tures cri­tiques de l’État¹⁴.