Modernisation des systèmes hérités fédéraux : pourquoi la plupart des efforts échouent et ce qui fonctionne

Pourquoi la plupart des efforts stagnent et ce qui fonctionne

La modernisation des systèmes hérités fédéraux n'est pas un problème nouveau. Les agences parlent depuis des années de systèmes vieillissants, de langages obsolètes, d'intégrations fragiles, d'exposition à la cybersécurité et de coûts de maintenance croissants. Ce qui est différent aujourd'hui, c'est que la modernisation devient liée à presque toutes les autres priorités : l'adoption de l'IA, la cybersécurité, la prestation de services, l'efficacité, la planification de la main-d'œuvre et la résilience de la mission.

Les preuves ne sont pas encourageantes. En juin 2019, le Government Accountability Office (GAO) a identifié dix systèmes fédéraux hérités critiques ayant le plus besoin de modernisation. En juillet 2025, le GAO a rapporté qu'en février 2025, seuls trois de ces dix efforts de modernisation avaient été achevés. Quatre étaient censés se terminer dans les prochaines années, deux devraient prendre cinq ans ou plus, et un n'avait toujours pas de date d'achèvement prévue. C'est une longue période pour des systèmes déjà considérés comme critiques il y a des années.

Le Congrès y prête également attention. En avril 2026, un groupe bipartite de législateurs de la Chambre des représentants a introduit la Loi de 2026 sur la réduction des TI hérités, H.R. 8408. Le projet de loi obligerait les directeurs des technologies de l'information (CTO) des agences à inventorier les systèmes hérités et obligerait les chefs d'agence à élaborer des plans quinquennaux pour les mettre à jour, les moderniser, les mettre hors service ou les éliminer. La visibilité et la planification ne résoudront pas la modernisation à elles seules, mais elles constituent des points de départ nécessaires.

La leçon principale est simple : la modernisation des systèmes hérités échoue lorsqu'elle est traitée comme un projet de relocation technologique plutôt que comme un projet de transformation opérationnelle.

Pourquoi cela importe maintenant

Les systèmes hérités ne sont plus seulement une gêne interne pour les TI. Ils affectent directement la capacité des agences à faire évoluer l'IA, à se défendre contre les menaces cyber, à améliorer les services aux citoyens et à s'adapter aux besoins changeants de la mission.

L'enquête 2026 sur l'efficacité fédérale d'EY’ a révélé que 86 % des décideurs fédéraux voient des obstacles à l'échelle de l'IA dans des solutions à l'échelle de l'agence. Le principal obstacle était la difficulté d'intégrer de nouvelles solutions d'IA avec les systèmes TI hérités, citée par 48 % des répondants. Les lacunes en compétences et en formation de la main-d'œuvre étaient également un obstacle majeur, cité par 44 %.

Ces chiffres comptent car ils relient deux conversations souvent traitées séparément. Les agences ne peuvent pas devenir prêtes pour l'IA tout en laissant leurs systèmes centraux fragiles, mal documentés et difficiles à intégrer. L'IA ne se situe pas au-dessus de la modernisation. De plus en plus, l'IA dépend de la modernisation.

Un modèle peut être impressionnant dans un bac à sable, mais l'IA en production a besoin d'accès aux données, d'intégration système, de contrôles d'identité, de surveillance, de sécurité, de conception de flux de travail et de gouvernance. Les environnements hérités rendent souvent chacun de ces éléments plus difficile.

Le piège du lift-and-shift

La migration lift-and-shift peut être utile. Déplacer un système vers une infrastructure cloud peut réduire la charge des centres de données, améliorer les options de disponibilité ou créer un chemin vers une modernisation ultérieure. En mai 2026, un conseiller technologique senior au Département des Transports a exhorté les agences à envisager des stratégies lift-and-shift pour moderniser les systèmes hérités sans interruption de service. Ce conseil peut être pragmatique dans le bon contexte.

Le piège est de considérer cela comme la ligne d'arrivée.

Un monolithe hébergé sur le cloud reste un monolithe. Une intégration fragile ne devient pas flexible parce qu'elle fonctionne sur une infrastructure plus récente. Une règle métier mal documentée ne devient pas claire parce que le serveur a changé d'emplacement. Un système avec des processus de publication fragiles, des interfaces obsolètes, une observabilité faible ou des hypothèses codées en dur peut toujours présenter les mêmes risques opérationnels après la migration.

Le lift-and-shift peut être une phase. Il peut gagner du temps. Il peut réduire certains risques. Mais si la seule chose qui change est l'endroit où le système s'exécute, l'agence a relocalisé la dette technique plutôt que de moderniser le système.

La modernisation concerne vraiment la connaissance de la mission

La partie la plus difficile de la modernisation des systèmes hérités n'est souvent pas le code. C'est la connaissance intégrée dans le code.

De nombreux systèmes hérités se sont développés autour d'années de changements de politique, d'exceptions opérationnelles, de contournements manuels, de besoins de reporting et d'habitudes institutionnelles. Certaines règles métier n'ont jamais été entièrement documentées car les personnes maintenant le système savaient comment il fonctionnait. Certaines structures de données reflètent des décisions prises il y a des décennies. Certains flux de travail existent en raison de contraintes qui ne s'appliquent plus, tandis que d'autres existent en raison d'exigences légales ou de mission qui comptent absolument toujours.

Une équipe de modernisation qui ne comprend pas ces distinctions est en difficulté.

C'est pourquoi le remplacement des systèmes hérités ne peut pas commencer avec l'hypothèse que l'ancien système est simplement mauvais et que le nouveau sera meilleur. L'ancien système peut être laid, coûteux et difficile à maintenir, mais il peut également contenir une logique de domaine critique qui maintient le fonctionnement de l'agence.

L'objectif n'est pas de préserver chaque bizarrerie. L'objectif est de comprendre quels comportements sont accidentels, lesquels sont essentiels et lesquels devraient être repensés.

Le fossé des compétences s'élargit

La modernisation fédérale fait également face à un problème de main-d'œuvre. Les personnes qui comprennent les anciens systèmes, langages, interfaces et flux de travail spécifiques aux agences approchent souvent de la retraite ou sont déjà surchargées. Les nouveaux techniciens peuvent comprendre le cloud, les API, DevOps, les pratiques de sécurité modernes et les flux de travail alimentés par l'IA, mais manquent du contexte de domaine intégré dans l'environnement hérité.

C'est là que les projets de modernisation peuvent stagner.

Si les experts des systèmes hérités ne se voient pas accorder le temps de transférer leurs connaissances, les équipes perdent le contexte. Si les ingénieurs modernes ne sont pas exposés à la réalité opérationnelle de la mission, ils conçoivent des systèmes élégants qui manquent de contraintes importantes. Si la documentation est traitée comme une après-pensée, le nouveau système peut répéter la même dépendance aux connaissances tribales qui a rendu l'ancien système fragile.

Le transfert de connaissances doit être un livrable. Pas un plus. Pas quelque chose coincé dans le dernier mois d'un projet. Un livrable.

Les calendriers politiques et techniques ne correspondent pas toujours

La modernisation fédérale rencontre également un problème structurel de timing. Les travaux sérieux de modernisation prennent souvent des années. Les priorités politiques peuvent changer plus vite que cela. Les changements de leadership, les cycles budgétaires, la pression de la surveillance changent, et de nouveaux mandats arrivent avant que les anciens ne soient achevés.

C'est une raison pour laquelle les plans de modernisation quinquennaux sont utiles mais pas suffisants. Un plan peut créer de la visibilité, mais il a toujours besoin d'un ancrage durable. Les efforts de modernisation devraient être liés aux résultats de la mission, aux exigences statutaires, aux risques de cybersécurité, à la continuité opérationnelle et aux améliorations de service mesurables plutôt qu'au langage d'une seule administration ou cycle de leadership.

Plus un effort de modernisation dépend d'un récit de priorité temporaire, plus il est facile pour cet effort de perdre de l'élan.

Ce qui fonctionne mieux

Les efforts de modernisation réussis ont tendance à suivre un modèle plus discipliné.

• Définir la modernisation comme un changement architectural, pas un déplacement d'infrastructure : Le rehosting peut être utile, mais la vraie modernisation améliore la maintenabilité, l'intégration, la sécurité, l'observabilité, la vitesse de livraison et l'adaptabilité de la mission.
• Inventorier les systèmes honnêtement : Les agences doivent savoir ce qui existe, qui en est propriétaire, ce que cela coûte, quels risques cela crée, quelle fonction de mission cela soutient et quelles dépendances l'entourent.
• Documenter la logique de domaine : Le comportement hérité doit être capturé avant que des décisions de remplacement ne soient prises. Les équipes doivent savoir quelles règles comptent, lesquelles sont des artefacts historiques et lesquelles peuvent être simplifiées.
• Intégrer le transfert de connaissances dans le plan : Associer les experts des systèmes hérités aux ingénieurs, analystes et architectes modernes avant que les connaissances institutionnelles ne disparaissent.
• Moderniser de manière incrémentielle lorsque c'est possible : Les réécritures big-bang sont risquées. Les modèles strangler, les couches API, l'extraction de services, la modernisation des données et la migration par phases peuvent réduire les perturbations.
• Concevoir pour la continuité : Les plans de modernisation doivent survivre aux changements de leadership en liant le travail aux résultats de la mission, aux risques de sécurité, aux besoins de conformité et à la valeur opérationnelle mesurable.
• Rendre l'intégration une exigence de premier ordre : Les systèmes modernes doivent se connecter à l'IA, à l'analytique, à l'identité, à la gestion des dossiers, au reporting et aux écosystèmes partenaires. L'intégration ne peut pas être ajoutée à la fin.

Le fil conducteur est que la modernisation doit être traitée comme un programme de compréhension, de séquencement et d'exécution. Pas un événement d'approvisionnement. Pas un échange de plateforme. Pas une migration cloud seule.

L'IA augmente les enjeux

L'IA a rendu la modernisation des systèmes hérités plus urgente car elle expose la faiblesse des fondations fragiles. Les agences veulent que l'IA aide à l'analyse, l'automatisation, la détection de fraude, les services aux citoyens, la cybersécurité, le tri des dossiers, le traitement des documents et la planification de la mission. Mais l'IA dépend de données et de flux de travail souvent piégés dans les systèmes hérités.

Si les données sont incohérentes, inaccessibles, mal documentées ou difficiles à gouverner, l'IA aura du mal. Si les processus métier sont fragmentés à travers des systèmes obsolètes, l'automatisation alimentée par l'IA peut simplement amplifier la confusion. Si l'identité, la journalisation et les contrôles d'accès sont faibles, l'IA introduit de nouveaux risques de gouvernance et de sécurité.

Cela ne signifie pas que chaque système hérité doit être remplacé avant qu'une agence puisse utiliser l'IA. Cela signifie que la planification de l'IA et la planification de la modernisation doivent être connectées. Sinon, les agences peuvent investir dans des pilotes d'IA qui ne peuvent pas évoluer car les systèmes dont ils dépendent ne sont pas prêts.

Comment Ridiculous Engineering pense la modernisation

Chez Ridiculous Engineering, nous abordons la modernisation comme un problème à la fois technique et de connaissance du domaine. La technologie compte, mais le premier défi est de comprendre ce que le système existant fait réellement, pourquoi il se comporte ainsi et quelles parties de ce comportement doivent survivre à la transition.

C'est particulièrement important dans les environnements publics et d'entreprise complexes où les systèmes codent souvent des années de politique, de processus, de conformité, de reporting et d'exceptions opérationnelles. Remplacer le logiciel sans comprendre ces règles est la façon dont la modernisation crée de nouveaux risques.

Nous aidons les organisations à réfléchir à la modernisation par étapes pratiques : évaluation de l'état actuel, inventaire des systèmes, cartographie des flux de travail et des données, découverte de la logique de domaine, planification de l'intégration, évaluation de l'architecture, migration par phases et support à la mise en œuvre. L'objectif est de réduire les risques tout en améliorant la capacité de l'organisation’ à fonctionner, intégrer, sécuriser et faire évoluer le système au fil du temps.

Pour les organisations se préparant à l'adoption de l'IA, ce travail devient encore plus important. Les systèmes prêts pour l'IA ont besoin de données accessibles, d'intégrations fiables, de gouvernance, de surveillance et d'une propriété claire. La modernisation des systèmes hérités est souvent la fondation qui rend ces capacités possibles.

La modernisation doit être exécutable

La modernisation des systèmes hérités fédéraux n'échoue pas parce que les agences manquent de conscience. Le problème est bien connu. Il échoue lorsque les plans sont trop vagues, le transfert de connaissances a lieu trop tard, les exigences sont incomplètes, les calendriers ignorent la réalité et les choix technologiques sont traités comme des substituts au jugement architectural.

La Loi sur la réduction des TI hérités pointe dans la bonne direction en mettant l'accent sur l'inventaire et la planification. Mais la législation seule ne modernisera pas un système. Les agences ont toujours besoin d'une exécution disciplinée, d'une découverte solide, d'un financement durable, d'une propriété claire et d'équipes capables de traduire les besoins de la mission en changements techniques.

Si votre organisation évalue la modernisation des systèmes hérités, se prépare à la préparation à l'IA ou essaie de réduire les risques dans un portefeuille d'applications vieillissantes, Ridiculous Engineering peut vous aider. Nous travaillons avec les clients pour clarifier l'état actuel, capturer les connaissances du domaine, concevoir des chemins de modernisation réalistes et construire des systèmes plus faciles à exploiter, intégrer et améliorer.

La modernisation ne consiste pas seulement à remplacer l'ancienne technologie. Il s'agit de préserver ce dont la mission a besoin tout en supprimant les contraintes qui empêchent l'organisation d'avancer.

Sources et lectures complémentaires : GAO : Les agences doivent planifier la modernisation des systèmes hérités critiques datant de décennies, FedScoop : Loi de 2026 sur la réduction des TI hérités, EY : Les efforts d'efficacité des agences gouvernementales fédérales font face à des obstacles significatifs, MeriTalk : Conseiller du DOT exhorte à la voie lift-and-shift, AWS : Cadre pour la modernisation accélérée et la réduction de la dette technique