Au-delà du cloud souverain : la dépendance aux logiciels métiers

L'IA peut rendre la réversibilité des logiciels métiers enfin envisageable, sans supprimer la difficulté des migrations. Faisons de la capacité de reconstruire un critère de souveraineté numérique.

Au-delà du cloud souverain : la dépendance aux logiciels métiers

Le débat public se concentre sur l'hébergement des données et la nationalité des éditeurs. L'intelligence artificielle ouvre un autre front : contribuer à rendre exerçable la réversibilité des logiciels dont dépend l'État, à condition de ne pas confondre réécrire du code et reconstruire un système d'information.

Depuis vingt ans, la souveraineté numérique se discute à propos du cloud, des données et des infrastructures. Une dépendance plus profonde reste pourtant dans l'angle mort : celle qui nous lie aux logiciels eux-mêmes.

Une administration achète un logiciel pour dix, quinze ou vingt ans. Les évolutions deviennent coûteuses, les compétences s'éteignent, la documentation vieillit, et le fournisseur devient incontournable. Une part considérable du fonctionnement de l'État repose ainsi sur des milliers d'applications dont presque personne ne maîtrise l'intégralité, parfois après des décennies de couches techniques successives.

Le droit de la commande publique connaît pourtant la réversibilité, la portabilité des données et le dépôt de sources. Mais ces clauses sont rarement exercées, pour une raison simple : le coût réel d'une sortie est dissuasif. Quitter un éditeur, c'est comprendre l'existant, en extraire les règles métier, réécrire ou reparamétrer, puis migrer. Une réversibilité que l'on ne peut pas exercer n'est qu'une promesse.

C'est ce que l'IA pourrait changer. Analyser une application complexe, en documenter le fonctionnement et en extraire les règles métier devient envisageable, et sa réécriture peut être en partie accélérée. L'IA peut ainsi réduire le coût de la compréhension et de la transformation de certaines applications, sous réserve de vérifier les règles métier extraites et les résultats obtenus. L'IA ne rend pas les systèmes d'information réversibles ; elle peut rendre la réversibilité enfin envisageable, et la faire passer de la clause théorique à l'option réaliste.

Il faut toutefois rester lucide : réécrire du code n'est pas reconstruire un système d'information. La bascule de la messagerie de l'Éducation nationale, qui remplace la solution Convergence d'Oracle, devenue obsolète, par une messagerie nationale, en donne une idée. Ce parc représente, à l'échelle du ministère, plus de deux milliards de messages, et l'académie de Normandie vient d'y basculer. Les consignes aux agents montrent que la difficulté tient à ce qui entoure le code : carnet d'adresses à exporter avant la bascule, contacts et agendas non synchronisés, archives locales des clients de messagerie non reprises, postes à reparamétrer. Les identifiants académiques, eux, sont conservés. Cet exemple ne prouve pas ce que l'IA sait faire ; il rappelle ce qu'elle ne supprime pas : la recette, l'exploitation, la conduite du changement.

Reconstruire n'est pas non plus copier. Dans l'affaire SAS Institute (2012), la Cour de justice de l'Union européenne a jugé que ni les fonctionnalités d'un logiciel, ni son langage de programmation, ni ses formats de fichiers ne sont protégés en tant que tels par le droit d'auteur. Une implémentation indépendante est donc possible, mais dans des conditions juridiquement encadrées : l'observation et l'étude du fonctionnement par l'acquéreur légitime ne sont permises que dans certaines limites, et copier le code, contourner une licence ou reproduire une documentation protégée ne l'est pas. La frontière est fine, et les administrations devront s'outiller juridiquement avant de s'outiller techniquement.

Enfin, l'IA peut créer une dépendance nouvelle. Du code généré en masse, mal compris et mal documenté, serait aussi opaque que l'ancien, et les modèles qui le produisent relèvent pour l'essentiel de fournisseurs extra-européens. La souveraineté suppose donc, avec les droits d'usage, les compétences et les moyens de maintenance, une compréhension réelle du logiciel : savoir ce qu'il fait, pourquoi, et pouvoir le démontrer. La documentation des règles métier en devient un actif stratégique.

La capacité de reconstruire devrait ainsi devenir un critère de souveraineté, au même titre que l'hébergement ou la cybersécurité. Les acheteurs publics peuvent en tirer des exigences concrètes : portabilité effective des données, documentation vivante des processus, tests réguliers d'un export complet et d'une restauration ailleurs, plan de sortie chiffré et actualisé chaque année. Car un hébergement "de confiance" protège de certains accès aux données ; il ne démontre pas, à lui seul, la capacité de changer d'éditeur. Les deux sujets doivent être traités séparément.

Demain, les États les plus autonomes ne seront pas forcément ceux qui possèdent tous les logiciels, mais ceux qui auront conservé la capacité de maintenir, remplacer ou reconstruire leurs fonctions essentielles. Cette ambition devient techniquement plus accessible. Reste à la rendre juridiquement sûre et opérationnellement crédible.