Intégrer l'IA, ce n'est pas changer tes systèmes : c'est leur poser un pont
La première image que presque tout le monde a de « mettre de l'IA dans l'entreprise » est fausse : il ne s'agit pas d'arracher l'ERP que tu paies depuis huit ans pour le remplacer par un truc neuf avec un chatbot dedans. Intégrer l'IA, c'est l'inverse — on laisse tes systèmes là où ils sont et on tend un pont entre eux et le modèle. L'ERP reste la source de vérité, le CRM garde tes contacts, le gestionnaire de documents continue d'archiver ; ce que tu ajoutes, c'est une couche qui lit et écrit dedans avec discernement. Le pont, pas le remplacement.
Ça compte parce que l'endroit où la plupart des projets meurent, ce n'est pas le modèle : c'est la connexion. Un agent qui rédige des réponses parfaites ne vaut rien s'il ne peut pas lire la commande dans ton ERP ni laisser la note dans ton CRM. La bonne question n'est pas « quel modèle j'utilise ? », c'est « comment je parle à ce que j'ai déjà sans le casser ? ». Ce guide parle de ça : les vraies façons de connecter, quand utiliser chacune et où les intégrations cassent.
Les trois façons de connecter l'IA à ce que tu as déjà
Il n'y a pas une seule façon de tendre le pont. Il y en a trois, et elles se distinguent par le contrôle et le travail qu'elles demandent en échange. La plupart des architectures sérieuses en combinent deux.
API directe (REST / GraphQL)
La voie la plus propre quand ton ERP ou ton CRM expose déjà une API moderne. Le système d'IA appelle l'API pour consulter des données, exécuter une action ou réagir à un événement via webhook. Contrôle maximal et latence minimale, en échange de quelqu'un qui code et maintient cette connexion. C'est l'option par défaut pour HubSpot, Salesforce, Shopify ou tout système pensé pour ce siècle. Le problème arrive avec l'ERP de 2004 qu'il faut envelopper dans un middleware avant qu'il parle à quoi que ce soit.
Couche d'orchestration / iPaaS (Zapier, Make, n8n)
Au lieu de coder chaque connexion, on utilise une plateforme d'intégration qui embarque déjà des centaines de connecteurs prêts. L'IA déclenche le flux et la couche d'orchestration enchaîne les actions — créer l'enregistrement, déplacer le fichier, envoyer l'email — sans backend sur mesure. Plus rapide à monter et plus facile à changer ; en échange, tu dépends des connecteurs qui existent et d'une plateforme de plus sur la facture. C'est le raccourci sensé pour passer en production en quelques semaines quand les systèmes sont standard.
MCP, le connecteur standard (l'« USB-C de l'IA »)
MCP (Model Context Protocol) est un standard ouvert pour connecter les modèles à tes données et tes outils sans réécrire l'intégration pour chaque modèle que tu utilises. L'analogie qui marche, c'est l'USB-C : avant, chaque entreprise qui voulait brancher un modèle sur son CRM construisait un câble sur mesure ; MCP standardise la prise. Sa valeur, ce n'est pas la vitesse d'aujourd'hui, c'est que tu arrêtes de t'enchaîner à un fournisseur : tu changes de modèle et le pont tient toujours. En 2026, les grands fournisseurs le supportent, donc c'est le pari d'architecture, pas une expérience.
Comment décider laquelle utiliser
Le choix n'est pas une question de goût, c'est une question de contexte : à quoi ressemblent tes systèmes, quel volume tu déplaces et à quel point tu veux dépendre d'un tiers. Pour t'orienter :
| Situation | Voie recommandée | Pourquoi |
|---|---|---|
| Systèmes modernes avec une bonne API, gros volume | API directe | Contrôle et latence ; le coût du code s'amortit avec l'usage |
| Systèmes standard, tu veux produire vite | Orchestration / iPaaS | Connecteurs prêts, zéro backend, tu changes le flux sans toucher au code |
| Plusieurs modèles ou prévision d'en changer | MCP | Un seul pont qui ne se refait pas quand tu changes de fournisseur |
| ERP legacy sans API correcte | API directe + middleware | Il faut d'abord envelopper le vieux système ; c'est là que part le budget |
La gouvernance : permissions, audit et frein à main
Donner à un système d'IA l'accès à ton ERP et à ton CRM, c'est lui donner une clé. Une intégration adulte ne mise pas sur la confiance : elle mise sur les permissions. Trois contrôles ne sont pas optionnels :
- Permissions à portée limitée (scoped). L'agent voit et touche seulement ce que sa tâche exige, pas tout le système. Authentification par OAuth 2.0, tokens qui tournent, identifiants qui expirent. Un agent de support ne devrait pas pouvoir supprimer une facture.
- Piste d'audit. Chaque lecture et chaque écriture du système d'IA est enregistrée : ce qu'il a touché, quand et pourquoi. Sans piste, aucun moyen de reconstruire une erreur ni de la défendre devant qui te la demande.
- Frein à main. Un interrupteur qui coupe l'accès de l'agent en quelques secondes si ça dérape, et une frontière claire des actions qui exigent un feu vert humain avant de s'exécuter. L'autonomie sans frein, ce n'est pas de l'autonomie : c'est de l'exposition.
Les quatre points où une intégration casse
Les intégrations ne cassent pas à cause du modèle. Elles cassent presque toujours aux mêmes quatre endroits, et tous se voient venir :
- La donnée sale ou inaccessible. Si l'input vit dans un PDF scanné ou dans un WhatsApp, aucune API ne le sauve. L'intégration commence par mettre la donnée là où on peut la lire.
- Le système legacy sans API. Le vieil ERP oblige au middleware, et ce travail n'est presque jamais dans le budget initial. Découvre-le à l'audit, pas sur la facture.
- Les limites de débit (rate limits). Les systèmes ont été conçus pour des personnes qui cliquent sur des boutons, pas pour un agent qui fait mille appels par minute. Si tu ne dimensionnes pas le rythme, l'intégration marche dans la démo et tombe en production.
- L'absence de propriétaire. Une intégration est un système vivant : les formats changent, les connecteurs cassent, des cas limites apparaissent. Sans personne pour la maintenir, elle se dégrade en quelques mois. C'est la même raison pour laquelle tant de projets d'automatisation échouent.
Quand tu décides quoi connecter en premier, la réponse vient du processus, pas de la technologie : commence par celui qui fait le plus mal et qui a la meilleure donnée, c'est exactement le critère de quels processus automatiser avec l'IA. On tend le pont vers là où il y a du trafic.