Connecter l'IA à son ERP : API, connecteurs et bonnes pratiques

Un dirigeant nous arrête souvent à ce moment précis de la discussion. On vient de lui montrer qu'une IA peut lire ses commandes reçues par mail et préparer la saisie. Il hoche la tête. Puis : « D'accord, mais concrètement, ça rentre comment dans mon ERP ? »

C'est la bonne question. Et derrière elle se cache une peur légitime, celle de devoir tout changer. Beaucoup imaginent qu'automatiser suppose de remplacer leur logiciel de gestion, ou de le faire trafiquer par un intégrateur pour des dizaines de milliers d'euros. Rassurez-vous. Dans l'immense majorité des cas, on ne touche pas à l'ERP. On branche l'automatisation autour de lui.

Reste à savoir par où. Un ERP, ce n'est pas une boîte fermée : il a des portes. Certaines sont larges et bien indiquées, d'autres sont des portes de service qu'il faut connaître. On va les passer en revue une par une, du cas le plus simple au plus coriace, avec les noms des outils qui vont bien.

Deux mondes qui doivent se parler

Posons le décor. D'un côté, votre ERP : Sage, Divalto, EBP, Cegid, Odoo, ou un logiciel métier plus confidentiel développé jadis pour votre secteur. Il contient vos articles, vos clients, vos commandes, vos stocks, votre compta. C'est le coffre-fort de l'entreprise, et il tourne, souvent depuis des années.

De l'autre, une automatisation qui s'appuie sur de l'IA. Elle lit un email, comprend une facture PDF, rédige une réponse, décide d'un routage. Elle est agile, récente, elle vit dans le cloud ou sur un petit serveur à part.

Entre les deux, il faut un pont. La question « connecter l'IA à son ERP » revient à demander : comment l'automatisation lit-elle ce qu'il y a dans le coffre, et comment y dépose-t-elle son travail sans tout casser ? Il existe trois grandes réponses. On les prend dans l'ordre.

Voie 1 : l'API, quand elle existe

Une API, c'est une porte prévue exprès pour que d'autres logiciels viennent discuter avec le vôtre. Un guichet officiel, avec des règles claires : voici comment tu demandes la fiche du client 4072, voici comment tu crées une commande, voici ce que je te renvoie. Propre, documenté, fait pour durer.

Quand votre ERP en propose une, c'est la voie royale. Les échanges sont fiables, en temps quasi réel, et on lit comme on écrit sans passer par des fichiers intermédiaires. Sage propose des API sur ses versions récentes, notamment la gamme Sage 100 et l'univers cloud. Cegid, Odoo et les ERP modernes en ont aussi. Divalto expose des services web sur ses éditions actuelles.

Concrètement, à quoi ça sert ? Prenez le traitement d'une commande arrivée par mail. L'IA a lu le message, identifié le client, extrait les références et les quantités. Via l'API, l'automatisation va d'abord vérifier que le client existe bien dans l'ERP et récupérer son compte, contrôler que les articles sont au catalogue, puis créer la commande directement, au bon format, avec les bons codes. Personne ne ressaisit rien.

Voilà pour la théorie. Dans la vraie vie, deux réserves reviennent tout le temps.

• L'API existe, mais elle est bridée. Certains éditeurs facturent l'accès, limitent le nombre d'appels par jour, ou n'exposent qu'une partie des données. On vérifie toujours ce qui est réellement ouvert avant de promettre quoi que ce soit.
• L'API existe, mais pas sur votre version. C'est le cas le plus fréquent. Vous êtes sur une édition de 2015 qui marche très bien, et l'API n'est arrivée que trois versions plus tard. Il faudrait migrer pour l'avoir. On y revient, parce que c'est le vrai nœud.

Quand l'API est là et accessible, on la privilégie sans hésiter. C'est le lien le plus stable, celui qui résiste le mieux aux montées de version et qui demande le moins d'entretien dans le temps.

Voie 2 : les exports et imports, la porte que tout le monde a déjà

Pas d'API ? Ce n'est pas un mur. Presque tous les ERP, même anciens, savent faire deux choses toutes bêtes : sortir des données dans un fichier, et en avaler.

Votre logiciel exporte des factures en CSV chaque soir ? L'automatisation lit ce fichier. Il accepte l'import de commandes via un fichier plat au format attendu ? L'automatisation le génère et le dépose. On travaille avec ce que l'outil propose déjà, sans lui demander de faire ce pour quoi il n'a pas été conçu.

Ça paraît rustique. Ça l'est un peu. Mais c'est souvent d'une solidité à toute épreuve, parce que ces formats d'échange existent depuis vingt ans et ne changent jamais. Un import CSV que Cegid ou EBP gère depuis une décennie ne va pas se mettre à bouger du jour au lendemain.

Le déroulé type ressemble à ceci. L'ERP dépose chaque nuit un export du catalogue articles et de l'encours client dans un dossier. Une plateforme d'orchestration récupère ces fichiers, les met à disposition de l'IA pour qu'elle travaille sur des données fraîches, et en fin de traitement produit un fichier d'import que l'ERP ira lire à son tour. Le pont est fait de fichiers, pas d'appels directs, mais il tient.

Deux points de vigilance, tout de même. Le décalage, d'abord : si l'export tourne la nuit, l'automatisation travaille sur les données d'hier soir, ce qui convient pour beaucoup de tâches mais pas pour tout. Le format, ensuite : un séparateur qui change, un accent mal encodé, une colonne ajoutée, et l'import plante. On verrouille ces formats et on prévoit un contrôle qui alerte au lieu de laisser passer une erreur en silence.

Voie 3 : le connecteur et le robot, pour les ERP qui ne veulent rien lâcher

Reste le cas dur. L'ERP maison écrit il y a quinze ans, sans API, sans export propre, ou dont personne ne connaît plus les entrailles. Le logiciel métier de niche, spécifique à la plasturgie ou à la découpe, que trois entreprises en France utilisent. Là, on sort deux autres outils.

Le premier, ce sont les plateformes d'orchestration. n8n, Make ou Zapier jouent le rôle de chef d'orchestre entre l'IA, vos boîtes mail, vos fichiers et votre ERP. Elles savent déclencher une action quand un mail arrive, appeler un modèle de langage comme Claude pour comprendre le contenu, puis pousser le résultat vers la bonne destination. Beaucoup embarquent des connecteurs tout faits pour les ERP courants, ce qui évite de tout recoder.

Le second, c'est le robot logiciel, ce qu'on appelle la RPA. L'idée est presque enfantine : un programme pilote l'interface de l'ERP comme le ferait une personne. Il ouvre l'écran de saisie, clique dans les champs, tape les valeurs, valide. L'ERP ne voit pas la différence avec un opérateur humain, sauf que le robot ne se trompe pas de touche à 17 h un vendredi.

C'est laid vu du capot, on ne va pas prétendre le contraire. Un robot qui clique dans des menus est plus fragile qu'une API : si l'éditeur déplace un bouton à la prochaine mise à jour, il faut ajuster. Mais pour un vieux Sage ligne 30 ou un applicatif métier fermé, c'est parfois la seule porte, et elle fonctionne. On combine d'ailleurs souvent les deux logiques, l'IA qui comprend et la RPA qui exécute, un sujet qu'on détaille dans notre article sur les règles pour marier RPA et IA.

Les droits et les données : qui a le droit de faire quoi

Brancher une automatisation sur un ERP, ce n'est pas juste une affaire de tuyaux. C'est aussi une question de permissions, et elle mérite qu'on s'y arrête, parce que c'est là qu'on voit passer les vraies bêtises.

Première règle : on crée un compte dédié pour l'automatisation. Pas le compte du DAF, pas celui de l'assistante ADV. Un utilisateur technique, avec un nom clair du genre « auto-ia », qui n'a accès qu'à ce dont il a besoin. Si l'automatisation ne fait que lire les commandes et créer des devis, elle n'a rien à faire dans les écrans de paie ou de trésorerie. Le moindre privilège, toujours.

Deuxième règle : chaque action de l'automate laisse une trace. Qui a créé cette commande, quand, à partir de quel mail ? Un bon branchement est traçable de bout en bout. Le jour où un chiffre paraît bizarre, on veut pouvoir remonter le fil en trente secondes, pas se demander si c'est l'humain ou la machine qui a saisi.

Et puis il y a la donnée elle-même, celle qui sort de chez vous pour être comprise par un modèle d'IA. Notre principe est simple : on envoie le strict minimum. Pour lire une facture fournisseur, l'IA a besoin du PDF de la facture, pas de tout votre grand livre. On choisit des services dont l'éditeur s'engage à ne pas réutiliser vos échanges pour entraîner ses modèles, et tout ce qui engage vraiment l'entreprise, une commande, un paiement, passe par une validation humaine avant d'être écrit dans l'ERP. Vos données restent maîtrisées, l'IA n'est qu'un exécutant encadré.

Les pièges qu'on connaît par cœur

Il y a des sujets qui reviennent sur presque chaque projet de connexion. Autant les nommer d'avance.

Les champs personnalisés et les usages détournés

Aucun ERP n'est utilisé comme dans le manuel. Sur le terrain, on trouve toujours des bricolages : un champ « commentaire » qui sert en réalité de statut de dossier, un code article dont les trois premiers caractères encodent une info que seul le chef d'atelier décrypte, un champ maison ajouté il y a cinq ans par un intégrateur parti depuis. Ces conventions ne sont écrites nulle part. Elles vivent dans les têtes.

Une automatisation qui les ignore va écrire dans le mauvais endroit, ou lire de travers. D'où une étape qu'on ne saute jamais : cartographier les champs réellement utilisés, et ce qu'ils veulent dire pour vous, avant de brancher. Ça prend une demi-journée avec la bonne personne. Ça évite des semaines de galère.

Les versions et les mises à jour

On l'a dit pour l'API, ça vaut pour tout : la version de votre logiciel change ce qui est possible. Une même marque, disons EBP ou Sage, propose des choses très différentes selon l'édition et l'année. On ne conçoit pas un branchement « pour Sage » en général, on le conçoit pour votre Sage, celui qui tourne chez vous avec son numéro de version précis.

Et une mise à jour de l'ERP peut, un jour, bouger une porte. Ça n'a rien de dramatique si le pont a été pensé pour, avec des points de contrôle et une alerte quand un format ne colle plus. Ce qui fait mal, c'est le branchement bricolé qui casse en silence et qu'on découvre trois semaines plus tard, quand les commandes ne sont plus passées.

La qualité des données existantes

Un doublon client, une fiche article avec un prix à zéro, une adresse mail périmée : votre ERP contient déjà des scories, comme tous les ERP. L'automatisation ne les invente pas, mais elle les met en lumière, parce qu'elle traite en masse ce qu'un humain corrigeait au cas par cas sans le dire. C'est presque une bonne nouvelle. Souvent, connecter l'IA devient l'occasion d'un premier nettoyage utile de la base.

Pourquoi on ne change surtout pas d'ERP pour automatiser

Voici notre position, et elle est tranchée. Changer d'ERP pour pouvoir automatiser est presque toujours une mauvaise idée.

On comprend la tentation. Un commercial vous explique que son nouvel outil est « nativement compatible IA », que tout serait plus simple avec lui, qu'il faut vivre avec son temps. Le raisonnement paraît logique. Il est piégeux.

Parce qu'un ERP, ce n'est pas qu'un logiciel. C'est des années de paramétrage, des centaines d'habitudes, une comptabilité qui s'y déverse, des interfaces avec la banque ou le transporteur, et surtout des équipes qui le connaissent sur le bout des doigts. Le remplacer, c'est un chantier de douze à dix-huit mois, un budget à cinq ou six chiffres, une reprise de données casse-tête, et une période de flottement où plus personne ne s'y retrouve. Tout ça pour, à la fin, faire ce qu'on aurait pu faire autour de l'ancien.

Car l'automatisation se moque de l'âge de votre ERP. Elle a besoin d'une porte, on l'a vu, et il y en a toujours une : API, export, ou robot. Un vieux logiciel métier sans API se connecte très bien par RPA. Ça demande un peu plus de soin, pas une migration.

La bonne démarche est l'inverse de celle du commercial. On garde l'ERP qui fait déjà tourner l'entreprise, on lui ajoute une couche d'automatisation par-dessus, et on va chercher les gains tout de suite. Si un jour un changement d'ERP se justifie pour de vraies raisons métier, ce sera un projet à part, décidé pour lui-même, pas une rançon payée à l'IA. C'est la même logique que celle du développement d'automatisation sur mesure : on s'adapte à l'existant, on ne le rase pas.

Nos bonnes pratiques, en clair

Si on devait résumer une connexion réussie en quelques principes, ce serait ceux-là.

• Commencer par cartographier. Quelle version, quelle porte disponible, quels champs vraiment utilisés, quels usages détournés. Une demi-journée bien investie qui évite les mauvaises surprises.
• Privilégier l'API, se rabattre sur l'export, garder la RPA pour le reste. Dans cet ordre de solidité. On ne complique pas quand une porte simple existe.
• Un compte dédié, au moindre privilège. L'automatisation n'accède qu'à ce qu'elle traite, et chacune de ses actions est tracée.
• Un humain valide ce qui engage. L'IA prépare, propose, remplit. La création d'une commande ou d'un paiement passe par un œil humain, au moins au début.
• Des garde-fous qui alertent. Un format qui change, un doublon, un montant aberrant : le système prévient au lieu de laisser filer. On préfère un signal de trop qu'une erreur silencieuse.
• Ne pas toucher à l'ERP. On branche autour. Le coffre-fort reste le coffre-fort.

Rien de sorcier là-dedans. Juste de la méthode, et l'habitude de regarder d'abord ce qui existe avant de dégainer la solution la plus lourde. La connexion à l'ERP, ce n'est pas la partie glamour d'un projet d'automatisation. C'est celle qui décide s'il tient dans la durée ou s'il s'écroule à la première mise à jour.

Une automatisation qui traite les documents mais ne sait pas déposer proprement son travail dans le système de gestion ne sert pas à grand-chose. C'est pour ça qu'on soigne ce pont autant que le reste, notamment sur les projets de gestion documentaire par l'IA où tout finit, tôt ou tard, par devoir rejoindre l'ERP.