Vos agents IA ne garantissent pas la cohérence de votre SI
Beaucoup de PME espèrent qu'un agent IA va discrètement mettre de l'ordre dans des données mal structurées. C'est l'inverse qui se produit, l'IA amplifie ce que votre SI ne garantit pas déjà.
Donatien Lefranc
Fondateur & Président, Leando
La promesse implicite derrière « on va brancher un agent IA dessus »
Une phrase revient souvent dans les discussions sur la modernisation du SI, on va mettre un agent IA sur ce processus, il va nous aider à y voir plus clair. Derrière cette phrase se cache une attente plus large que ce qu'un agent IA peut réellement tenir, l'espoir que l'intelligence artificielle compense une structure de données qui n'a jamais été posée clairement, sans qu'il faille faire ce travail de structuration soi-même.
Cette attente part d'une confusion compréhensible. Un agent IA manipule le langage et les données avec une aisance impressionnante, il paraît donc logique qu'il puisse aussi remettre de l'ordre dans des données désorganisées. Sur le terrain, l'expérience montre le contraire, un agent IA reproduit et amplifie la structure qu'on lui donne, il ne la crée pas à partir du désordre.
Cette confusion coûte cher parce qu'elle inverse l'ordre logique du chantier. Une direction qui espère qu'un agent IA va compenser un modèle de données jamais clarifié repousse le vrai travail, celui de nommer les objets métier, de trancher les zones de flou, de documenter les règles implicites, en pariant qu'un outil externe le fera à sa place. Le résultat le plus fréquent n'est pas l'échec spectaculaire du projet IA, c'est un projet qui avance, produit des résultats plausibles, et qui grave dans le système les mêmes incohérences qu'avant, simplement plus vite et à plus grande échelle qu'un humain ne l'aurait fait seul.
Pourquoi l'IA accélère vos erreurs de conception au lieu de les corriger
Sur un projet de développement assisté par IA, une équipe a vu un outil générer du code parfaitement cohérent en apparence, reliant des interlocuteurs à des contrats et des entreprises. Le problème n'était pas dans le code, il était dans l'hypothèse métier sous-jacente, jamais vérifiée, alors que dans la réalité du client, ces interlocuteurs se rattachaient à des sites, pas à des contrats. L'outil a dû défaire puis reconstruire, parce que l'IA avait produit une logique plausible mais fausse, faute d'une règle métier explicite pour la corriger en amont.
Ce n'est pas un cas isolé. La vitesse d'exécution que permet l'IA transforme un flou de conception, auparavant lent à se révéler, en défaut immédiat et visible. Ce qui prenait plusieurs sprints à faire remonter comme problème structurel remonte désormais en quelques heures, sous forme de bugs silencieux ou de comportements inattendus. L'IA ne fait pas apparaître ces angles morts par magie, elle exécute simplement plus vite ce qu'on ne lui a pas dit de ne pas faire.
Le même mécanisme se retrouve sur des sujets plus modestes que l'architecture d'un système entier. Sur la conception d'un récapitulatif de tarification pour un outil de staffing événementiel, une équipe a soumis à une IA une demande de mise en forme d'informations complexes, tarifs, majorations, règles de calcul par équipe. L'IA a produit une proposition structurée, avec hiérarchie visuelle et code couleur. Ce que ce résultat a révélé n'était pas une solution de design, c'était que l'équipe n'avait encore jamais tranché quelle information devait primer, pour qui, et dans quel ordre. L'IA a forcé cette clarification en produisant une structure, elle ne l'avait pas résolue à la place de l'équipe, elle l'avait simplement rendue visible.
La ligne que Leando trace en atelier de cadrage
Sur un chantier de structuration SI chez un fournisseur d'énergie ETI, cette limite a été posée explicitement au client au moment d'évoquer l'usage d'agents IA sur certains processus.
« Un système d'information, à partir du moment où tu veux de la structure et surtout de la consistance dans les données, il ne faut pas que ce soit les agents IA qui soient les garants de cette consistance. »
Cette phrase ne condamne pas l'usage d'agents IA, elle situe leur rôle, une brique à un endroit précis du système, jamais le garant de sa cohérence d'ensemble. La cohérence reste un problème d'architecture et de règles métier explicites, porté par le SI lui-même, avant même de se poser la question de quel outil IA brancher dessus.
La couche de contexte : ce qu'il faut formaliser avant de brancher l'IA sur votre métier
Structurer un SI pour qu'il garantisse sa propre cohérence est un chantier d'architecture. Un autre chantier, plus accessible et souvent négligé, consiste à formaliser ce qu'on appelle chez Leando la couche de contexte, le vocabulaire métier, les décisions passées et des cas réels catégorisés, écrits noir sur blanc plutôt que dispersés dans la tête de quelques personnes.
Cette couche se distingue nettement des inventaires de données opérationnelles qu'un projet IA industriel exige avant de démarrer, mesures, enregistrements, historiques destinés à un traitement automatisé. La couche de contexte porte sur un autre registre, le langage que votre entreprise utilise pour parler d'elle-même, les raisons derrière des choix passés que personne n'a jamais eu besoin d'écrire parce que tout le monde en interne les connaissait déjà. Un outil IA peut recevoir des données opérationnelles parfaitement propres et produire malgré tout un résultat générique, s'il ne dispose d'aucun accès à ce second registre.
Sans cette couche, un outil IA généraliste, même connecté à vos documents internes, régresse vers une moyenne de ce qu'il a vu ailleurs. Il produit un contenu correct sur la forme, mais générique sur le fond, parce que le positionnement réel de votre entreprise, ce qui la distingue de la concurrence, n'existe nulle part sous une forme qu'il peut exploiter. Ce constat a été fait directement en construisant l'infrastructure de contenu de Leando elle-même, à partir de cas projets rédigés en markdown, de verbatims clients catégorisés et de métadonnées d'images décrites une par une, plutôt que de données brutes livrées telles quelles à l'outil.
Pour un état des lieux plus large sur les tensions que crée l'IA quand elle s'installe sans cadre commun dans une organisation, l'article sur ChatGPT utilisé en silo dans chaque poste montre comment l'absence de cadre partagé aggrave la fragmentation plutôt que de la résoudre.
À faire cette semaine
- ☐ Choisissez un seul processus métier critique et listez les termes que personne chez vous n'a jamais eu besoin de définir par écrit
- ☐ Décrivez deux ou trois décisions passées sur ce processus, avec la raison qui les a motivées, pas seulement le résultat final
- ☐ Testez un outil IA généraliste sur une question de ce processus, avant puis après lui avoir fourni ce contexte écrit
- ☐ Vérifiez, dans votre SI, si une règle métier repose aujourd'hui sur la vigilance d'une personne plutôt que sur une contrainte structurelle
Ce que ce principe exclut, et où il s'arrête
Ce principe n'exclut pas l'usage d'agents IA sur des tâches bornées, où l'entrée, la sortie attendue et les effets de bord sont fixés à l'avance par un humain. Il exclut de leur confier, sans cette structure, la responsabilité implicite de maintenir la cohérence d'un système entier. Sur la manière de tracer cette limite tâche par tâche, l'article sur la règle de décision pour confier une tâche à l'IA seule détaille les trois bornes à poser avant toute délégation.
La distinction compte particulièrement pour un dirigeant qui a déjà investi dans un premier agent IA et qui commence à en attendre plus que ce pour quoi il a été conçu. Le signal à surveiller n'est pas l'échec visible de l'agent, c'est la tentation progressive de lui confier des décisions qui touchent à la structure même du système, sans jamais avoir posé, en amont, qui reste responsable de cette structure quand l'agent se trompe.
Il ne s'applique pas non plus de la même façon à une PME qui commence tout juste à digitaliser ses processus, où la priorité reste de poser une première structure de données avant même de penser IA, et à une entreprise déjà équipée d'un SI structuré, où la question devient celle du contexte métier à formaliser pour que l'IA en tire une valeur spécifique plutôt que générique.
Il existe enfin une limite budgétaire à ne pas ignorer, une fois qu'un agent IA tourne en production sur un processus réel, il doit être surveillé dans la durée exactement comme n'importe quel autre composant du SI. Une PME qui n'a pas prévu de budget pour ce suivi continu se retrouve avec un agent qui dérive silencieusement, sans que personne ne le remarque avant qu'un résultat visible en pâtisse. Le coût de fonctionnement d'un agent IA ne s'arrête pas à sa mise en production, il inclut le temps humain nécessaire pour vérifier qu'il continue de bien faire ce pour quoi il a été conçu.
Avant de brancher votre prochain agent IA sur un processus interne, écrivez d' abord une page sur le vocabulaire et les règles de ce processus que personne chez vous n'a jamais formalisées, même sommaire, même incomplète au premier jet. Si cette page n'existe pas encore, l'IA que vous vous apprêtez à installer va deviner à la place de vos équipes, pas garantir la cohérence que vous recherchez.
Il peut signaler des écarts statistiques évidents, pas juger si une donnée reflète correctement votre métier. Un agent IA raisonne sur ce qui semble logique en général, pas sur les règles spécifiques de votre activité. Sans une structure de données qui porte déjà ces règles, il produit du code ou des réponses cohérents en apparence, mais faux sur le fond, exactement comme le ferait un stagiaire qui découvre votre métier le jour même.
Votre SI garantit-il sa propre cohérence, ou compte-t-il sur l'IA pour le faire à sa place ?
30 minutes pour identifier où votre structure de données dépend encore de la vigilance d'une personne.
Réserver un échange de diagnostic