IA et logiciels anciens : 4 approches sans réécriture

Remplacer un système en place depuis des années n’est ni un passage obligé ni, souvent, une bonne idée. Plusieurs méthodes permettent d’ajouter de l’IA autour d’un cœur applicatif intact, à condition de cadrer l’accès, de prévoir les coûts continus et de choisir une architecture adaptée. Tour d’horizon des options, des vérifications préalables et des pièges récurrents.

Anticiper les coûts et limiter l’accès au départ

Les API de modèles de langage commerciaux sont généralement facturées par token. À ces coûts s’ajoutent les dépenses liées à la surveillance, à l’évaluation et au réentraînement, qui nécessitent un engagement financier permanent après la mise en service. Les équipes qui abordent une couche d’IA comme une opération unique constatent fréquemment une perte de performance au fil de l’évolution des données et du contexte, tandis qu’un budget d’exploitation prévu dès le début permet de maintenir la stabilité de la fiabilité. Côté gouvernance, la recommandation est de débuter par des usages en lecture seule — recherche, synthèse, reporting — afin d’établir des mesures d’exactitude avant toute action modifiant des données. L’accès en écriture intervient ensuite, assorti d’étapes d’approbation humaine pour les opérations sensibles.

Quatre architectures pour isoler le cœur applicatif

Garder l’IA à distance du système central est présenté comme l’option la plus sûre. Une première voie consiste à intercaler une couche middleware qui n’expose que des opérations définies, empêchant toute requête arbitraire sur la base de production et limitant les risques de surcharge, d’erreurs de requêtes ou d’injection de prompt. La génération augmentée par récupération offre une seconde piste : les données restent dans le système ancien, tandis qu’un pipeline séparé indexe le contenu utile dans une base vectorielle et permet des réponses enrichies de citations pour vérification. Troisième approche : l’intégration pilotée par événements s’appuie sur l’émission d’événements ou la capture de données de changement — insertions, mises à jour, suppressions — pour déclencher des services d’IA en quasi temps réel, capables par exemple de signaler des transactions suspectes ou de prédire un retard sans alourdir l’application historique. Enfin, le modèle du figuier étrangleur — nommé par Martin Fowler — remplace ou augmente des fonctions morceau par morceau via une façade, l’ancien système continuant pour le reste et l’équilibre évoluant sans coupure unique risquée.

Pourquoi éviter la réécriture générale

Les applications anciennes incorporent des années de règles métier, de cas particuliers et de logique réglementaire, rarement documentées de façon exhaustive. Une réécriture impose de les redécouvrir tout en gardant l’existant en production, avec des projets de remplacement réputés pour dépasser budgets et délais, et dont certains n’aboutissent pas. Par ailleurs, l’IA fonctionne mieux sur des données fiables et des processus stables : l’épreuve du temps constitue une base solide que fournit précisément un système mature.

Ce que l’état du système impose en amont

Avant toute phase de développement, il convient d’établir si le système est en mesure de fournir des données par le biais d’API ou si la création d’une couche d’intégration supplémentaire est nécessaire. La qualité et l’uniformité des données déterminent la faculté d’un modèle à extraire ou assimiler l’information. Il convient aussi d’identifier les détenteurs des processus concernés et les exigences de sécurité et de conformité applicables, ces éléments pilotant l’architecture et réduisant les risques de surprises en cours de projet.

Ajouter une couche, pas rebâtir : la trajectoire recommandée

Beaucoup d’organisations supposent que l’IA impose de tout reconstruire, ce qui freine les initiatives, alors qu’une réécriture d’un système en place depuis 15 ans est coûteuse, risquée et rarement nécessaire. Dans la plupart des cas, l’IA peut s’ajouter comme une couche plutôt que comme une nouvelle fondation. Des sociétés de développement positionnent ainsi l’IA en extension de l’existant ; SumatoSoft décrit par exemple l’ajout d’une couche intelligente sans détruire ce qui fonctionne. Les logiciels anciens concentrent souvent les connaissances les plus précieuses de l’entreprise ; une couche d’IA peut transformer ces actifs en avantage plutôt qu’en chantier de migration. La trajectoire proposée est d’entamer par un cas d’usage étroit et de laisser les résultats réels guider l’ampleur de la montée en puissance.