Les systèmes legacy sont omniprésents dans les grandes organisations et dans beaucoup de PME structurées. Ils fonctionnent depuis dix ans, parfois vingt, sans interruption. Personne n’en maîtrise toutes les dépendances ni les points de fragilité. Personne ne veut les remplacer d’un coup, car cela paralyserait l’activité. Et pourtant, l’organisation souhaite y ajouter une couche IA intelligente pour améliorer la décision ou l’automatisation. Comment procéder sans casser ce qui marche actuellement ? Lionel Clément, co-fondateur de DécisionIA aux côtés de Gabriel Dabi-Schwebel, a accompagné plusieurs clients dans ce défi délicat et complexe. Le retour d’expérience terrain montre que la clé n’est pas technologique avant tout, mais organisationnelle et humaine.
L’intégration d’une IA dans un legacy est fondamentalement un effort de traduction et d’adaptation. Le système legacy parle un langage métier ancien et cristallisé ; le modèle IA en parle un plus nouveau et orienté données. Créer un pont solide entre les deux exige de comprendre comment les données circulent actuellement dans le legacy, où réside la logique métier critique, quels points de friction existent entre les équipes. Cette compréhension précède logiquement toute solution technique qui serait vouée à échouer sinon.
Cartographie et stratégie d’intégration pragmatique
Avant d’écrire une seule ligne de code ou de configurer le moindre modèle, il faut répondre à trois questions stratégiques. Premièrement, comment les données entrent-elles dans le legacy aujourd’hui ? Par fichiers Excel manuellement importés, par intégration API avec d’autres systèmes, par saisie manuelle dans des formulaires ? Deuxièmement, où l’IA va-t-elle ajouter concrètement de la valeur ? À quel point précis du flux ? Troisièmement, quels systèmes en aval consomment les résultats de l’IA, et comment les modifiera-t-elle ? Un exemple concret du terrain : un legacy gère le parcours client complet d’une grande banque. Les demandes de crédit immobilier arrivent, passent par une évaluation de risque longue ou par un vieux système de scoring datant de dix ans. DécisionIA considère l’intégration d’un modèle de machine learning pour améliorer cette évaluation et réduire le taux d’acceptation de mauvais dossiers, comme le démontre la pratique de comité éthique IA, comme le démontre la pratique de agents IA en production. Mais l’IA ne doit pas remplacer brusquement le flux existant ; elle doit l’augmenter intelligemment. Elle fournit une recommandation que l’analyste de risque humain peut valider, contester ou affiner. Cette distinction mentale — augmentation plutôt que remplacement total — est le secret du succès et de l’adoption.
La cartographie identifie les points d’ancrage concrets : les endroits où une API peut être créée sans casser le legacy, où un export de données est possible chaque nuit, où une saisie manuelle d’une prédiction peut être intégrée dans l’interface existante. Ces points d’ancrage deviennent les fronts tactiques d’intégration. On ne construit pas une solution monolithique ; on construit une succession d’adaptateurs souples et maintenables. La gestion des données du legacy requiert aussi une approche structurée. Les données du legacy sont rarement propres et bien structurées. Elles ont vingt ans de sédiment : des anomalies historiques jamais corrigées, des valeurs manquantes introduites par des migrations, des conventions de nommage inconsistantes entre les modules. Le consultant qui pense construire un modèle IA performant sur des données legacy sans préparation majeure s’expose à une surprise très désagréable à trois mois.
Préparer les données et construire la couche d’intégration
DécisionIA recommande une approche en deux temps solidement documentée. D’abord, une phase intense de compréhension des données : quelles sources sommes-nous obligés d’utiliser car critiques ? Quelles autres sources pourrions-nous ajouter pour améliorer la qualité sans complexifier le flux ? Deuxièmement, une phase systématique de préparation : nettoyage de chaque colonne, traitement des imputations manquantes, enrichissement si possible à partir de sources tierces fiables. Cette phase occupe souvent 40 pour cent de l’effort total du projet. Un client peut être frustré ou incrédule : « Vous me dites que cela prendra quatre semaines pleines juste pour préparer les données, avant même de construire le modèle prédictif ? » La réponse honnête est oui, c’est nécessaire et cela justifie le délai. Un modèle bâti sur des données mal préparées ne tiendra pas longtemps en production réelle.
L’IA ne parle pas naturellement le langage du legacy. L’IA prend un ensemble de chiffres en entrée et produit une prédiction chiffrée. Le legacy, lui, pense en termes métier : dossier client, demande de crédit, règle de validation métier. Il faut une couche intermédiaire qui traduit, adapte et réinterprète. Une approche techniquement simple est d’utiliser des API REST ou GraphQL. Le legacy expose un service qui accepte une demande de crédit formulée en langage métier, la transforme en vecteur numérique accepté par le modèle IA, appelle l’IA via une API, récupère la prédiction brute, la traduit en recommandation métier compréhensible, et la renvoie au legacy. Cette couche de traduction peut être construite relativement rapidement en deux à trois semaines ; elle ne requiert pas de modifier le cœur du legacy lui-même.
Une autre approche, plus légère et moins risquée, est d’utiliser des exports de données et des imports de résultats. Le legacy exporte chaque jour un fichier CSV des nouvelles demandes à traiter. Une tâche programmée la nuit appelle le modèle IA sur ce fichier, génère un fichier de résultats formaté. Un processus batch du legacy réimporte ce fichier et met à jour automatiquement les dossiers clients. Cette approche est moins « temps réel », mais elle est beaucoup plus facile à déployer dans une organisation où l’intégration API était complexe.
Conduire le changement et gouvernance post-lancement
Quand l’IA arrive soudainement dans le quotidien, elle change le rôle et le pouvoir des utilisateurs du legacy. Un analyste de risque qui avait une autonomie totale se voit soudain proposer une recommandation IA. Va-t-il l’accepter docilement ou la contester ? Va-t-il apprendre à faire confiance au modèle, ou va-t-il systématiquement la remettre en question ? Cette adoption humaine est souvent sous-estimée mais déterminante. La conduite du changement est déterminante pour la réussite réelle du projet. DécisionIA recommande de construire un groupe d’utilisateurs pionniers au sein du legacy, représentant les différents profils. Ces pionniers expérimentent la solution pendant six semaines avant un déploiement plus large vers l’organisation. Ils donnent un retour précieux, détectent les écueils cachés, gagnent de la confiance envers le modèle. Quand la solution est étendue à tous, ces pionniers deviennent des ambassadeurs auprès de leurs pairs. Une formation formelle sur le modèle IA et son fonctionnement global est aussi très utile. Qu’est-ce que le modèle apprend réellement sur les données ? Sur quels paramètres ou variables repose-t-il ? Quand ne doit-on absolument pas lui faire confiance ? Cette transparence crée une relation plus mature et honnête entre l’IA et son utilisateur.
L’intégration d’une IA dans un legacy ne s’arrête pas à la mise en production du jour zéro. Elle impose une gouvernance nouvelle et des processus. Quand le modèle se dégrade-t-il en performance ? Comment le détecter automatiquement ? Qui décide de le réentraîner ? Quelle est la procédure approuvée de déploiement d’une nouvelle version ? Comment revenir en arrière rapidement si c’est mal ? Le legacy, souvent, a une gouvernance IT rigoureuse et des processus de change management documentés. L’IA doit s’y adapter et s’y intégrer, non fonctionner en parallèle. Cela signifie documenter le modèle comme on documenterait un module logiciel classique, définir des tests automatisés de validation, mettre en place du monitoring continu, avoir une procédure testée de rollback en cas de problème. DécisionIA met l’accent sur l’agile dans les projets IA, car elle permet des cycles courts d’itération et de feedback. Cela fonctionne aussi très bien avec un legacy : des sprints de deux semaines, où on livre une amélioration incrémentale de la couche d’intégration ou du modèle lui-même. Chaque sprint passe par l’équipe de support du legacy et est testé en environnement contrôlé avant déploiement en production.
Anticiper les pièges et structurer le succès
Les pièges de l’intégration legacy-IA sont nombreux et documentés chez DécisionIA. Un client attend parfois que l’IA remplace une décision humaine totalement, mais DécisionIA rappelle dès le démarrage qu’une IA augmente une décision plutôt qu’elle la remplace. Cette distinction évite déceptions et mauvaises surprises ultérieures. Un autre piège classique est de sous-estimer cruellement la complexité réelle des données. Découvrir à trois mois que les données qu’on pensait disponibles ne le sont pas, ou qu’elles sont de piètre qualité, détraque un planning et frustre le client. Un article de DécisionIA sur la gestion des risques souligne que cette découverte tardive est un risque classique à anticiper dès le lancement et à valider de manière honnête.
Un troisième piège courant est l’abandon managérial après la mise en production. L’IA requiert du monitoring continu, de la maintenance périodique, des mises à jour du modèle. Un client qui espère « installer et oublier » l’IA aura inévitablement des déboires. DécisionIA structure ses contrats pour inclure systématiquement une phase d’accompagnement post-lancement de trois mois minimum, où le cabinet reste présent pour le support et l’optimisation. Cette approche garantit que le projet n’est pas abandonné au moment critique de la stabilisation.