L'auteur d'une plateforme d'assurance vieille de 20 ans a passé 108 tickets de support à travers un pipeline d'agents IA personnalisé, et le résultat est un flux de travail qui transforme une tâche de plusieurs heures, normalement réservée à un développeur senior, en quelques minutes seulement — un changement qui pourrait redéfinir la manière dont les entreprises maintiennent leur code hérité (legacy code) en vie.

Pourquoi les systèmes hérités comptent plus que le nouveau code

L'application d'assurance en question est un monolithe de 2,3 millions de lignes de code et d'environ 1 000 packages PL/SQL. Sa taille seule rend impossible pour une seule personne de maîtriser l'ensemble de la base de code. Ajoutez à cela un dédale de paramètres de configuration spécifiques aux clients, une documentation éparpillée et des archives de tickets remontant à 2017, et le véritable goulot d'étranglement devient la « recherche de contexte », et non l'écriture du code.

Le battage médiatique actuel autour de l'IA se concentre généralement sur la génération de nouveau code pour des projets greenfield. Dans ce cas précis, la difficulté ne réside pas dans la syntaxe du PL/SQL, mais dans la localisation de l'élément de logique exact, de la configuration pertinente et du ticket historique ayant décrit le problème pour la première fois. Un développeur expérimenté peut passer des heures à assembler des indices provenant de GitLab, SVN, de wikis et de vieux tickets de support. L'agent IA accomplit ce même travail en quelques minutes.

Le flux de travail en pratique

Lorsqu'un nouveau ticket arrive, l'auteur lance une commande unique. L'agent effectue ensuite les actions suivantes :

  • Récupère le texte du ticket et tous les fichiers joints via l'API du système de tickets.
  • Exécute une recherche par mots-clés et par vecteurs dans l'ensemble des archives de tickets pour faire remonter des cas passés similaires.
  • Interroge une bibliothèque personnelle de scripts SQL réutilisables.
  • Inspecte l'historique du code dans les systèmes de gestion de versions (GitLab ou SVN).

Toutes les conclusions sont compilées dans un seul fichier qui suggère également la prochaine étape — généralement un correctif de code, un projet de réponse au client ou une demande de diagnostics supplémentaires.

Capacités intégrées

L'auteur a défini 24 « compétences » pour l'agent, regroupées en quatre catégories :

  • Accès au contexte – lecture des API, des manuels et des bases de données pour extraire les faits pertinents.
  • Connaissance du domaine – interprétation des règles de comptabilité d'assurance et de l'architecture du système.
  • Rédaction – génération d'extraits PL/SQL et préparation de leur déploiement.
  • Méta – reconnaissance de modèles et création automatique de nouvelles compétences si nécessaire.

Ces compétences permettent à l'agent d'agir comme un ingénieur junior qui ne dort jamais, faisant remonter la ligne de code ou la configuration exacte mentionnée dans un ticket.

Filets de sécurité intégrés au processus

L'automatisation dans un environnement de production exige des garde-fous. L'auteur suit deux règles simples :

  1. Validation statique – chaque script généré est soumis à un EXPLAIN PLAN par rapport au schéma en direct. Cela permet de vérifier les erreurs de syntaxe ou de logique sans réellement exécuter le code.
  2. Confirmation par double modèle – un second agent IA indépendant examine tout changement jugé risqué. Si les deux modèles arrivent à la même conclusion, l'auteur procède ; sinon, le ticket est transmis pour une révision manuelle.

Ces vérifications empêchent le processus de devenir une boîte noire qui pourrait, par inadvertance, interrompre une transaction d'assurance critique.

Bénéfices cumulatifs

Le résultat de chaque ticket est rattaché à l'enregistrement du ticket, créant ainsi une base de connaissances vivante. Lorsqu'un problème similaire réapparaît des mois ou des années plus tard, l'agent peut lire non seulement la solution précédente, mais aussi le raisonnement qui y a conduit. En effet, chaque ticket résolu devient une donnée d'entraînement pour les futurs tickets, accélérant davantage le cycle.

Limites réelles

  • Les tests manuels subsistent – l'auteur valide toujours les changements dans un environnement de test avant leur mise en production.
  • Absence de mesures définitives – bien que le temps gagné semble substantiel, l'auteur n'a pas quantifié la réduction exacte en heures.
  • Configuration personnelle – l'implémentation actuelle réside sur une seule station de travail ; son déploiement à l'échelle d'une équipe nécessiterait des travaux d'ingénierie supplémentaires.

Ces contraintes empêchent l'approche d'être un produit clé en main, mais elles ne diminuent pas l'idée centrale : l'IA peut réduire le temps de collecte de contexte de plusieurs heures à quelques minutes.

À surveiller ensuite

L'expérience de l'auteur est une preuve de concept plutôt qu'une offre commerciale. Les prochaines étapes logiques incluent :

  • Formalisation des métriques – suivi du temps de résolution des tickets avant et après le pipeline d'IA pour construire un business case.
  • Déploiement en équipe – encapsuler l'agent sous forme de service partagé afin que plusieurs ingénieurs puissent bénéficier de la même base de connaissances.
  • Intégration avec la CI/CD – l'injection directe de scripts validés dans un pipeline d'intégration continue pourrait boucler la boucle, du ticket à la production, sans transfert manuel.

Si ces extensions réussissent, le modèle pourrait servir de référence pour d'autres entreprises aux prises avec des bases de code massives et ancrées.

À retenir

La véritable valeur de l'IA dans les environnements legacy ne réside pas dans l'écriture automatique de nouveau code, mais dans la mise en évidence instantanée du contexte approprié. En transformant des heures de travail d'investigation d'un développeur senior en quelques minutes, un flux de travail d'agents d'IA peut maintenir la fonctionnalité des systèmes vieillissants, réduire les coûts de support et construire progressivement un référentiel de connaissances auto-renforcé. L'expérience montre que, pour les logiciels legacy, le gain de productivité le plus important provient de la réduction drastique du temps de recherche de réponses, et non de la génération de nouveau code.