L’âge n’est pas le vrai frein
Beaucoup de systèmes vieux de plusieurs décennies tournent de façon fiable chaque jour. Pour l’IA, le problème est l’accès. Les données dorment dans une base qu’aucun outil moderne ne sait interroger, et les règles métier vivent dans un code que personne ne veut toucher.
Étape 1 : exposer les données
Commencez par l’accès en lecture. Répliquez les données dont vos cas d’usage IA ont besoin dans un entrepôt moderne, ou placez une API de lecture devant la base historique. Cela suffit déjà à rendre possibles le reporting, la recherche et les réponses aux questions, sans modifier le système cœur.
Étape 2 : encapsuler les actions clés dans des API
Identifiez ensuite les quelques actions dont l’automatisation a besoin : créer une commande, mettre à jour un client, passer une écriture comptable. Encapsulez chacune dans une API bien documentée, avec validation et journalisation. Les agents et les nouvelles applications appellent l’API ; seule l’API parle à l’ancien système.
Étape 3 : moderniser là où ça fait mal
Une fois les données et les actions accessibles, vous voyez quels modules ralentissent réellement l’activité. Reconstruisez-les d’abord, derrière les mêmes API, et laissez les parties stables tranquilles jusqu’à ce qu’une raison de les changer apparaisse.
Un enchaînement raisonnable
La plupart des organisations avec lesquelles nous travaillons suivent à peu près cet ordre :
- Mois 1–2 : réplication des données et API de lecture pour le premier cas d’usage
- Mois 2–4 : API d’action pour les workflows à automatiser
- À partir du mois 4 : reconstruction des modules les plus coûteux à faire évoluer
Inventorier le processus avant la technologie
Commencez par la tâche qui nécessite un meilleur accès, pas par l’ouverture de tout le système. Identifiez utilisateurs, dossiers, décisions et actions, puis sources et propriétaires. Un champ bien nommé n’est pas nécessairement la référence, surtout après des années d’exports et de tableurs autour du système central.
Opérateurs et mainteneurs révèlent validations, rapprochements et exceptions absents de la documentation. Distinguez connu, supposé et à tester. Le premier résultat est une cartographie permettant un changement limité : choisir une frontière sûre de lecture ou d’action sans exiger de comprendre et remplacer tout le patrimoine.
La lecture exige un contrat de données
Réplication et API de lecture modifient accès et attentes de fraîcheur. Définissez identifiants, sens des champs, droits et actualisation avant le nouveau consommateur. Préservez les distinctions historiques utiles au lieu de tout réduire à la dernière valeur affichée.
Définissez propagation des suppressions, corrections et retards. Le chatbot peut devoir préciser la date ou refuser une question urgente. Le reporting doit distinguer absence d’activité et rafraîchissement échoué. Testez dossiers absents, changements de droits et rapprochement avec le cœur. Le système historique reste la référence tandis qu’une interface contrôlée rend les données utiles accessibles.
Encadrer les actions plus strictement que la lecture
L’écriture présente un risque différent. Préférez une petite opération aux entrées validées et au résultat explicite à un accès général en écriture. L’interface impose règle métier et autorisation même si l’appelant se trompe. Les actions sensibles ou difficiles à annuler suivent la validation convenue.
Un timeout ne prouve pas l’échec : le cœur peut avoir accepté. Identifiants d’opération, suivi de statut et rapprochement évitent les répétitions. Conservez assez d’informations pour enquêter sans copier inutilement des données sensibles dans les journaux. Testez doublons, rejets, dépendances indisponibles et échecs partiels. Cette frontière sert au logiciel classique même si l’action n’est jamais confiée à un agent.
Choisir une frontière de migration vérifiable
La modernisation progressive demande des responsabilités transférables. Choisissez module ou processus dont entrées, sorties et acceptation sont observables. Gardez la compatibilité et définissez le propriétaire du dossier pendant la transition. La nouvelle version ne doit pas créer silencieusement deux références concurrentes.
Migration d’essai ou comparaison parallèle révèle les écarts avant bascule. Convenez des contrôles, signataires et conditions de retour arrière. Historique, identifiants et rapports comptent même si l’interface fonctionne. Retirez les composants après transfert des responsabilités et preuve d’acceptation. L’objectif est de réduire le coût du changement tout en préservant l’activité, pas de déclarer la refonte finie au premier déploiement.
Séparer l’IA du cœur métier
La fonction IA utilise les interfaces contrôlées sans les contourner. Les questions documentaires suivent sources et droits. L’agent suit opérations autorisées, validations et traitement d’échec. La sortie du modèle reste une entrée du système, pas une permission d’ignorer ses règles.
Versionnez consignes, récupération et évaluations avec le code d’intégration. Testez informations absentes, anciennes ou restreintes et actions impossibles à exécuter sûrement. L’utilisateur reçoit explication et alternative. Ce découplage réduit l’impact d’un changement de modèle : le contrat reste observable. Le métier juge l’IA sur une vraie tâche sans rendre le cœur dépendant d’une décision conversationnelle opaque.
Le transfert est une exigence d’exploitation
La couche ajoutée a besoin d’un responsable. Documentez sources, droits, publication, alertes et reprise. Quelqu’un doit savoir examiner données anciennes, résultat incertain et interface historique modifiée. Les mainteneurs disposent du code et de la configuration, avec secrets dans les contrôles serveur ou plateforme convenus.
La séquence de ce guide est un exemple de préparation, pas un calendrier universel. Périmètre, interfaces, qualité et contraintes déterminent le projet. Un audit choisit conserver, encapsuler, réparer ou remplacer et quoi valider d’abord. Comparez avec les fourchettes de modernisation et d’intégration, puis confirmez par écrit. Un processus peut devenir accessible, observable et maintenable sans promettre de tout reconstruire.
Répéter le transfert sur une tâche réelle
Avant la validation, demandez à un opérateur qui n’a pas construit l’intégration d’exécuter une tâche représentative à partir du guide d’exploitation. Incluez une dépendance indisponible ou un résultat incertain. Vérifiez qu’il peut identifier l’état, retrouver le dossier et appliquer la reprise convenue. Traitez les lacunes des instructions comme du travail de livraison plutôt que de supposer que l’équipe retiendra une démonstration. Conservez une courte trace expliquant le choix de la frontière, de la source et du critère de retour arrière. Le prochain mainteneur comprend ainsi le raisonnement de la configuration, sans rouvrir chaque décision antérieure.
