La plupart des projets d'agents IA ne calent pas sur le modèle de langage. Ils calent sur le raccordement au système d'information. Un agent capable de traiter une commande, de relancer un impayé ou de préparer un devis n'a d'intérêt que s'il peut lire et écrire dans votre ERP ou votre CRM. Et c'est précisément là que les difficultés commencent — non pas parce que la technologie manque, mais parce que le terrain n'est pas prêt à l'accueillir.
On ne peut pas automatiser le chaos. Un agent branché sur des données incomplètes ou des interfaces instables ne fait qu'accélérer la production d'erreurs. Avant d'écrire la première ligne de connecteur, cinq questions déterminent si votre projet tiendra dans le temps ou s'éteindra au bout de trois mois.
1. Vos données sont-elles accessibles et propres ?
Un agent ne devine rien. Il travaille avec ce qu'il trouve. Si votre base client contient des doublons, des champs vides, des formats hétérogènes ou des statuts contradictoires, l'agent héritera de tous ces défauts — et il les amplifiera à la vitesse d'exécution d'une machine.
La question n'est pas seulement « les données existent-elles ? » mais « sont-elles exploitables sans intervention humaine à chaque étape ? ». Avant de connecter quoi que ce soit, il faut savoir où vivent les données utiles, dans quel état elles se trouvent, et qui garantit leur qualité. Une organisation requêtable — dont l'information est structurée, nommée clairement et interrogeable de façon fiable — est la condition d'entrée, pas un objectif secondaire.
2. Vos API sont-elles stables et documentées ?
Un agent dialogue avec votre SI par des interfaces. Si ces interfaces changent sans préavis, si elles ne sont pas documentées, ou si elles n'existent tout simplement pas pour les modules concernés, l'intégration devient un chantier permanent.
Les questions à poser à votre éditeur ou à votre équipe technique :
- Existe-t-il une API officielle pour les fonctions visées, ou faut-il passer par des contournements ?
- Cette API est-elle versionnée et maintenue dans le temps ?
- La documentation est-elle à jour et reflète-t-elle le comportement réel du système ?
Un agent posé sur une API non documentée ou instable est un agent condamné. Chaque mise à jour de l'ERP risque de le casser, et personne ne saura pourquoi.
3. Vos processus sont-ils cartographiés ?
Automatiser un processus suppose de le connaître dans le détail. Or beaucoup de processus opérationnels ne sont écrits nulle part : ils vivent dans la tête de quelques personnes, avec leurs exceptions, leurs cas particuliers et leurs arrangements informels.
Avant de confier une tâche à un agent, il faut la décrire précisément : quelles sont les étapes, les conditions de déclenchement, les points de décision, les cas de sortie ? Ce travail de cartographie révèle souvent que le processus réel diffère du processus supposé. C'est inconfortable, mais c'est utile : un agent ne fonctionne bien que sur un processus explicite. S'il reste implicite, l'automatisation se limitera aux cas les plus simples et retombera sur l'humain à la moindre exception.
4. Vos droits d'accès sont-ils définis ?
Un agent qui écrit dans votre CRM ou déclenche des actions dans votre ERP agit avec des droits. Lesquels ? Sur quels périmètres ? Avec quelles limites ?
La question de la gouvernance des accès est trop souvent traitée après coup. Elle doit l'être avant. Un agent doit disposer d'un compte identifié, avec des permissions strictement adaptées à sa mission — ni plus, ni moins. On doit pouvoir tracer chacune de ses actions, savoir ce qu'il a modifié et quand, et être capable de le suspendre instantanément.
Pour une ETI ou une PME, cet enjeu rejoint celui de la souveraineté : garder la maîtrise de qui accède à quoi, sur des infrastructures dont on contrôle la localisation et les règles. Ce n'est pas un supplément d'âme, c'est une condition de sécurité opérationnelle.
5. Qui maintient l'interface demain ?
C'est la question la plus négligée, et sans doute la plus déterminante. Un connecteur entre un agent et un SI n'est pas figé. Les logiciels évoluent, les API changent, les processus se modifient. Sans responsable clairement identifié pour maintenir l'interface, l'agent se dégrade silencieusement jusqu'à devenir inutile.
Il faut savoir dès le départ qui porte cette responsabilité : équipe interne, éditeur, prestataire ? Avec quel budget et quel niveau de service ? Un agent est un actif vivant. Sa durée de vie dépend directement de la solidité du dispositif de maintenance prévu.
Un exemple concret
Une PME industrielle de 180 personnes voulait automatiser la génération de ses accusés de réception de commande. Sur le papier, la tâche était simple : lire une commande entrante, vérifier la disponibilité, envoyer un accusé. En pratique, le diagnostic préalable a révélé que les stocks n'étaient fiables qu'à J+1, que l'ERP n'exposait pas d'API pour la vérification de disponibilité, et que trois personnes appliquaient des règles de priorité différentes selon les clients.
Résultat : le projet a d'abord porté sur la fiabilisation des stocks et l'harmonisation des règles de priorité. L'agent n'a été déployé qu'ensuite — et il fonctionne depuis sans intervention. Le diagnostic a évité un échec coûteux et transformé le projet en gain durable.
Le diagnostic conditionne la durée de vie
Ces cinq questions ne sont pas des freins. Elles sont le socle qui distingue un agent qui tient dans la durée d'une démonstration qui s'effondre en production. Le vrai travail se situe en amont : dans la qualité des données, la stabilité des interfaces, la clarté des processus et la solidité de la gouvernance.
Vous envisagez de connecter un agent IA à votre ERP ou à votre CRM ? Commençons par le diagnostic qui garantit sa durée de vie. Les équipes Lynakor évaluent la maturité de votre SI et identifient les prérequis avant tout déploiement. Contactez-nous pour un premier échange.