Pourquoi une IA sans accès à vos données ne sert à rien
Un modèle de langage sait lire, résumer, classer et rédiger. Il ne connaît ni vos clients, ni vos stocks, ni vos conditions commerciales. Sans accès à ces informations, il répond de façon générale, ou il invente une réponse plausible.
La valeur apparaît quand l'IA travaille sur vos données réelles : l'historique d'un compte dans le CRM, les commandes en cours dans l'ERP, les factures en attente. Et quand le résultat revient dans l'outil où les équipes travaillent déjà, plutôt que dans une fenêtre de discussion à part.
La question n'est donc pas « quelle IA choisir », mais « à quelles données donner accès, comment, et pour faire quoi ». C'est un sujet d'intégration avant d'être un sujet d'IA.
Les modes d'accès : API, connecteurs, exports, base de données, webhooks
Chaque logiciel a ses propres portes d'entrée. Le choix dépend de ce que l'éditeur autorise, du volume de données et de la fraîcheur attendue.
En pratique, on combine souvent plusieurs modes : un webhook pour déclencher le traitement, l'API pour lire le détail et écrire le résultat.
- API : l'interface prévue par l'éditeur pour lire et écrire des données de façon contrôlée. C'est la voie à privilégier quand elle existe et couvre les objets utiles.
- Connecteurs : des intégrations prêtes à l'emploi, proposées par l'éditeur ou par des outils de workflow sans code. Rapides à mettre en place, mais limités à ce qu'ils exposent.
- Exports : des fichiers produits à intervalle régulier, au format CSV ou tableur. Simples et robustes pour l'analyse, mais en lecture seule et jamais tout à fait à jour.
- Base de données : une lecture directe, de préférence sur une copie. Utile quand aucune API n'existe, si l'éditeur l'accepte. On n'y écrit jamais directement : ce serait contourner les règles de gestion du logiciel.
- Webhooks : des notifications envoyées par le logiciel quand un événement se produit, comme une nouvelle commande ou un changement de statut. Ils évitent d'interroger le système en boucle.
Lire d'abord, écrire ensuite
Un accès en lecture seule permet déjà beaucoup : consolider des chiffres, détecter des anomalies, préparer une synthèse avant un rendez-vous, signaler une commande bloquée. Le risque est faible : au pire, l'analyse est fausse, et un humain le voit.
L'écriture change la nature du projet. Créer une tâche, mettre à jour une fiche, modifier une commande : chaque action a un effet réel. On l'ouvre progressivement, objet par objet, une fois que la lecture a montré que les données sont fiables et que le système comprend ce qu'il manipule.
Cette progression suit les niveaux d'autonomie : observer et signaler (N0), proposer une action qu'un humain déclenche (N1), exécuter après validation (N2), puis exécuter seul sur un périmètre défini, chaque action étant journalisée (N3).
Le rôle de l'orchestration et du protocole MCP
Entre le modèle et vos logiciels, il faut une couche d'orchestration. Elle décide quand le système s'exécute, quelles données il reçoit, quels outils il peut appeler, et elle enregistre ce qu'il fait. Le modèle ne se connecte jamais directement à votre ERP : il passe par cette couche.
Le Model Context Protocol (MCP) est un standard ouvert qui normalise cette connexion. Un serveur MCP expose à l'agent une liste d'outils déclarés, par exemple « rechercher un client » ou « créer une tâche », chacun avec ses paramètres. L'agent ne peut appeler que ces outils : il n'a pas un accès libre au logiciel.
C'est ce qui permet de tracer un périmètre clair. Un agent chargé de préparer des relances peut lire les factures et créer des brouillons d'e-mail, sans pouvoir toucher à une écriture comptable. MCP ne remplace pas les permissions du logiciel : il s'y ajoute.
Sécuriser l'accès : comptes dédiés, permissions, journal, test
Le système dispose de son propre compte technique, distinct de celui d'un salarié. On sait ainsi qui a fait quoi, et on peut couper l'accès sans gêner personne.
Avant toute mise en service, il tourne sur un environnement de test : une copie du CRM ou de l'ERP, ou un bac à sable fourni par l'éditeur. On y vérifie son comportement sur des cas courants et sur des cas limites, sans toucher aux données de production.
- Permissions minimales : uniquement les objets et les actions nécessaires au cas traité.
- Journal : chaque écriture et chaque lecture sensible sont enregistrées, avec la donnée d'entrée, la décision et son motif.
- Réversibilité : pour chaque action, on sait comment l'annuler. Une action qui ne peut pas être défaite reste soumise à validation humaine.
- Secrets protégés : les clés d'accès sont stockées hors du code, renouvelées et révocables à tout moment.
- Données personnelles : on vérifie ce qui est envoyé au modèle, où il est hébergé, et ce que le RGPD impose pour ce traitement.
Ce qui bloque le plus souvent
Les difficultés viennent rarement de l'IA. Elles viennent des systèmes existants et de la façon dont ils sont tenus.
C'est le rôle de la capacité ENGINE chez OMEGA : connecter, structurer et fiabiliser les données avant de les confier à une analyse ou à un agent.
- API absente ou limitée : certains logiciels anciens n'en ont pas, d'autres n'exposent qu'une partie des objets ou plafonnent le nombre d'appels.
- Données sales : doublons, champs vides, statuts tenus à jour par certains et pas par d'autres. Une IA qui lit des données incohérentes produit des conclusions incohérentes.
- Référentiels multiples : le même client existe sous des noms différents dans le CRM, l'ERP et la comptabilité. Sans table de correspondance, aucun croisement n'est fiable.
- Règles implicites : une partie du processus n'existe que dans la tête des équipes. Tant qu'elle n'est pas écrite, le système ne peut pas l'appliquer.
- Conditions de l'éditeur : certains contrats encadrent l'accès automatisé ou le réservent à certaines offres.
Par où commencer
Partez d'un problème précis, pas d'un outil. Par exemple : « les commerciaux ne savent pas quelles commandes de leurs clients sont en retard ». Ce problème désigne les données nécessaires, le logiciel concerné et l'action attendue.
Ensuite, avancez par étapes courtes : prouver sur un cas, déployer, mesurer, puis étendre.
- Lister les données et les objets nécessaires, et vérifier comment chaque logiciel permet d'y accéder.
- Démarrer en lecture seule, sur un périmètre restreint, avec un compte technique dédié.
- Comparer les résultats du système avec ce que les équipes savent déjà, pour juger de sa fiabilité.
- Ouvrir l'écriture action par action, d'abord avec validation humaine, puis en autonomie quand le journal montre que c'est justifié.
- Mesurer l'effet sur le problème de départ avant d'étendre à d'autres cas.
