IA et legacy : du prompt au cadre de travail, retour sur une expérimentation terrain
IA et legacy : du prompt au cadre de travail, retour sur une expérimentation terrain
L’intelligence artificielle promet de transformer le développement logiciel. Mais que change-t-elle réellement lorsqu’elle s’applique à des systèmes existants, souvent complexes, imparfaits et hérités d’années d’évolution ? À travers une expérimentation menée sur un projet legacy, Soufiane Keli et Loïc Lefloch explorent une autre réalité de l’IA : celle d’un outil qui ne remplace pas le développeur, mais qui redéfinit profondément sa manière de travailler.
Un legacy comme terrain d’expérimentation
Depuis l’arrivée des modèles d’IA générative dans les environnements de développement, une promesse revient régulièrement : celle d’une transformation profonde du métier de développeur. Les assistants de code promettent d’accélérer la production logicielle, de réduire certaines tâches répétitives et, dans certains cas, de faciliter la compréhension de systèmes complexes.
Mais ces promesses se confrontent rapidement à une réalité bien connue des équipes techniques : celle des systèmes existants.
Dans la plupart des organisations, les développeurs ne passent pas leur temps à construire des applications à partir d’une page blanche. Ils travaillent sur des systèmes qui ont une histoire, une architecture parfois fragile, des dépendances accumulées et des décisions techniques prises plusieurs années auparavant. Bref, ils travaillent sur du legacy.
La question devient alors intéressante : que se passe-t-il lorsque l’IA s’invite dans ce contexte ?
Est-elle capable d’aider à comprendre et moderniser un système existant, ou reste-t-elle surtout efficace dans des environnements neufs et bien structurés ?
C’est précisément cette question que Soufiane et Loïc ont explorée à travers une expérimentation menée sur un projet interne. Le projet en question n’a rien d’exceptionnel. Au contraire, il ressemble à beaucoup d’outils internes développés dans les organisations. À l’origine, l’objectif était relativement simple : remplacer un fichier Excel utilisé pour certaines opérations par une application dédiée. La première version de l’outil est développée en 2016, avec l’idée de proposer une solution plus adaptée et plus robuste que le tableur initial.
Au fil des années, plusieurs stagiaires se succèdent sur le projet. Chacun apporte sa contribution : une nouvelle fonctionnalité, une amélioration technique, parfois une correction rapide pour répondre à un besoin immédiat. Progressivement, l’outil s’enrichit et trouve sa place dans le quotidien de certaines équipes. Mais cette évolution progressive a aussi un effet bien connu des développeurs : l’accumulation de dettes techniques. L’architecture n’a pas toujours été pensée pour durer, certaines conventions de code varient selon les contributeurs, et la documentation reste limitée.
Lorsque Soufiane et Loïc arrivent sur le projet, le constat est assez clair. L’application fonctionne, mais elle n’est pas réellement prête pour une utilisation en production. Plusieurs aspects doivent être retravaillés pour la rendre plus robuste : la sécurité, la qualité du code, la maintenabilité et l’architecture globale.
Mais ce point de départ soulève une autre question : plutôt que de moderniser ce système de manière classique, que se passe-t-il si l’on introduit l’IA comme levier principal de transformation ?
Passer du prompt à un cadre de travail
Plutôt que d’aborder ce chantier de modernisation de manière traditionnelle, ils décident d’en faire un terrain d’expérimentation.
L’idée est simple : tester concrètement ce que l’IA peut apporter dans un projet legacy.
Pour cela, ils adoptent une approche volontairement ambitieuse. Pendant plusieurs mois, ils vont chercher à coder le moins possible eux-mêmes et à s’appuyer autant que possible sur l’IA pour produire du code, analyser le système existant ou proposer des améliorations.
Mais très rapidement, une première limite apparaît.
Contrairement à l’image parfois véhiculée, il ne suffit pas d’écrire quelques prompts pour obtenir des résultats fiables. Les réponses produites par les modèles varient fortement selon la précision des instructions et la manière dont la demande est formulée.
Autrement dit, l’IA n’est pas immédiatement opérationnelle : elle doit être encadrée.
Soufiane et Loïc mettent alors en place un système de fichiers d’instructions destinés à guider le comportement du modèle. Ces fichiers décrivent précisément la manière dont certaines tâches doivent être réalisées : conventions de code, étapes à suivre, contraintes d’architecture. Progressivement, ces instructions deviennent une sorte de référentiel partagé entre l’équipe et l’IA. Mais cette structuration ne se fait pas en une seule fois. Au début, certaines réponses restent approximatives. Dans ces situations, les développeurs analysent les erreurs et ajustent les instructions afin d’améliorer les résultats. Ce travail d’itération permet peu à peu de stabiliser les interactions avec l’IA.
Ce processus fait émerger une logique intéressante : plutôt que de corriger les erreurs une par une, l’équipe améliore le système qui produit ces erreurs.
Les limites structurantes : contexte et compréhension
Mais structurer les instructions ne suffit pas à résoudre toutes les difficultés.
Très vite, un autre enjeu apparaît : la gestion du contexte.
Pour produire des réponses pertinentes, l’IA a besoin de comprendre le système sur lequel elle travaille. Pourtant, sa capacité à traiter l’information reste limitée. Trop de contexte peut rendre la réponse confuse, tandis qu’un manque d’information conduit à des résultats génériques.
Le travail consiste donc à trouver un équilibre : fournir suffisamment d’informations pour guider l’IA, sans la noyer dans un excès de détails.
Dans la pratique, cela conduit à adopter une approche plus fine. Les problèmes sont découpés en sous-tâches plus petites, plus faciles à traiter. Plutôt que de chercher une solution globale, l’équipe avance étape par étape.
Malgré ces contraintes, l’IA se révèle particulièrement efficace dans certaines situations. C’est notamment le cas lors de la phase de compréhension du code existant. Face à un module complexe ou peu documenté, elle peut rapidement proposer une synthèse du fonctionnement, expliquer les interactions entre composants ou suggérer des pistes d’amélioration. Dans un contexte legacy, cette capacité constitue un véritable accélérateur. Elle permet de réduire significativement le temps nécessaire pour appréhender un système existant.
Le rôle de développeur en pleine recomposition
Au fil de l’expérimentation, une évolution plus profonde apparaît : celle du rôle du développeur. Avec l’IA, écrire du code ne constitue plus l’unique cœur du métier. Le développeur devient également responsable de la manière dont l’IA est utilisée. Il conçoit les instructions, structure les interactions, analyse les résultats et valide le code produit. Il agit en quelque sorte comme un chef d’orchestre, garant de la cohérence d’ensemble.
Pour autant, certaines réalités du développement logiciel restent inchangées.
L’IA ne possède pas de compréhension métier. Elle ne porte pas de vision d’architecture. Elle peut proposer des solutions, mais elle ne peut pas décider de leur pertinence dans un contexte donné. Ces responsabilités restent pleinement humaines.
Mais cela ne signifie pas que l’IA est marginale. Au contraire, elle ouvre de nouvelles perspectives, notamment dans la modernisation des systèmes existants. En facilitant la compréhension du code, en accélérant l’exploration de solutions et en permettant de générer rapidement certaines implémentations, elle peut transformer la manière dont les équipes abordent le legacy.
Reste une question ouverte : jusqu’où cette transformation ira-t-elle ?
L’expérimentation menée par Soufiane et Loïc ne fournit pas toutes les réponses. Mais elle met en évidence un point essentiel : l’IA ne remplace pas les développeurs. Elle redéfinit leur rôle. Et comme souvent dans l’histoire du logiciel, ce sont probablement les équipes capables d’expérimenter, d’apprendre et d’adapter leurs pratiques qui tireront le meilleur parti de cette évolution.