Depuis deux ans, chaque éditeur de logiciel vous dit la même chose : votre ERP est trop vieux pour l’IA. Qu’il vous faut une plateforme cloud native. Que la migration est inévitable. Que les “systèmes modernes” sont la condition préalable à l’intelligence artificielle.

C’est une belle histoire. C’est aussi, dans la plupart des cas, faux.

L’IA n’a pas besoin que votre ERP soit sur le cloud. Elle a besoin que les données de votre ERP lui soient accessibles. Ce sont deux problèmes très différents — et le deuxième se résout sans toucher au premier.

Ce que les éditeurs ne vous disent pas

Quand un éditeur vous dit que “l’IA nécessite un ERP cloud natif”, il vous dit en réalité : “Achetez notre ERP cloud.”

Ce n’est pas un conseil technologique. C’est un argument de vente.

La réalité technique : l’IA — qu’il s’agisse de Claude, de GPT, ou d’un modèle local — a besoin d’accéder à des données. Elle ne se soucie pas de savoir si ces données viennent d’un AS400 de 1994 ou d’une API REST lancée hier. Ce qui compte, c’est l’interface d’accès.

Et cette interface d’accès, on peut la construire par-dessus n’importe quel système existant. Sans le remplacer. Sans le modifier. Sans même l’informer que quelque chose a changé.

L’architecture en pratique : le pattern connecteur

Sur le projet dont je parle ici, on avait cinq systèmes à intégrer :

  • Mapics / BPCS sur AS400 — l’ERP de production, tourne depuis les années 90, expose ses données via ODBC et DB2
  • Acomba — logiciel comptable québécois 32-bit (Windows, COM/OLE), utilisé pour la facturation et les clients
  • Progression Live — ERP de service terrain, API REST moderne
  • Isovision — gestion de la qualité, base de données SQL Server
  • GuideTI — guides de travail et gammes de fabrication

Cinq systèmes, cinq modèles de données différents, cinq façons d’exposer l’information. Et zéro ambition de les remplacer.

Le principe : chaque système a son propre connecteur. Un module isolé dont l’unique responsabilité est de lire les données de ce système et de les exposer dans un format standard. Le connecteur Mapics parle ODBC/DB2. Le connecteur Acomba gère le bridge COM/OLE. Le connecteur Progression Live appelle leur API REST.

Ces connecteurs ne se connaissent pas. Ils ne communiquent pas entre eux. Ils exposent tous vers un hub central — le seul endroit où les données se croisent.

Le hub ne sait pas que les systèmes sources existent. Il voit des interfaces standardisées. Si un ERP est remplacé demain, on remplace son connecteur. Le reste du système ne voit rien.

Le cas du pont 32-bit : Acomba

Le cas Acomba mérite un détail, parce qu’il illustre bien la classe de problèmes qu’on rencontre avec les ERP legacy Windows.

Acomba est une application 32-bit qui expose ses fonctionnalités via COM/OLE — une technologie Windows des années 90. C’est stable, c’est documenté, et c’est impossible d’appeler directement depuis un processus 64-bit moderne.

La solution qu’on utilise : un processus x86 séparé — une petite application 32-bit qui parle à Acomba via COM, et qui communique avec l’API principale (64-bit) via une file d’attente SQLite chiffrée en AES-256.

L’API moderne envoie une demande dans la SQLite. Le processus Acomba la lit, exécute l’opération, écrit la réponse. L’API récupère la réponse.

Ce n’est pas glamour. Mais c’est robuste, c’est sécurisé, et ça fonctionne. Des milliers de PME québécoises utilisent Acomba — le problème du pont 32-bit est réel et largement sous-documenté.

GraphQL comme couche d’unification

Une fois que les connecteurs exposent leurs données dans un format standard, il faut un moyen de les interroger de façon unifiée. On utilise GraphQL avec HotChocolate pour ça.

Un client (l’interface utilisateur, l’agent IA, n’importe quoi) peut demander : “Donne-moi les informations du client 1234, avec son historique de commandes Mapics, ses factures Acomba, et ses tickets de qualité Isovision.”

Une seule requête. Le hub résout les sources, croise les données, retourne un objet unifié. Le client ne sait pas (et ne doit pas savoir) que ces données viennent de trois systèmes différents.

C’est ce qu’on appelle des Type Extensions en GraphQL : chaque connecteur enrichit le même type de base (un Client, une Commande, un Produit) avec ses propres champs. De l’extérieur, ça ressemble à un seul modèle de données cohérent.

Le MCP server : brancher l’IA par-dessus

Une fois le hub en place, brancher un agent IA est presque trivial.

On construit un serveur MCP (Model Context Protocol) par-dessus le hub GraphQL. Le serveur MCP expose des outils à l’agent — pas des tables SQL, pas des endpoints REST bruts, mais des fonctions nommées avec des intentions métier claires :

  • GetClientRiskProfile(clientId) — retourne le profil de risque d’un client (historique de paiement Acomba + commandes en cours Mapics + tickets ouverts Isovision)
  • GetProductionCapacity(weekStart) — retourne la capacité disponible pour la semaine
  • GetAssemblageContext(productId, version) — retourne le guide de travail complet pour un assemblage

L’agent IA interroge ces outils en langage naturel. “Quel est le risque de délai sur les commandes de la semaine prochaine?” L’agent choisit les bons outils, croise les résultats, produit une réponse.

L’AS400, l’Acomba, les autres systèmes? Ils continuent de tourner exactement comme avant. Ils n’ont jamais su qu’un agent IA utilisait leurs données.

Pourquoi pas juste une API simple?

Question légitime. Pourquoi ce niveau d’architecture?

Parce que le but n’est pas juste d’accéder aux données une fois — c’est de construire une infrastructure durable qui peut évoluer sans tout reconstruire.

  • Quand Progression Live sort une nouvelle version de leur API, on met à jour le connecteur Progression Live. Rien d’autre ne change.
  • Quand vous ajoutez un sixième système (nouveau logiciel de maintenance, nouveau logiciel RH), vous ajoutez un sixième connecteur. Le hub, le GraphQL, le MCP — rien ne change.
  • Quand vous décidez dans 5 ans de remplacer Mapics par un ERP moderne, vous remplacez le connecteur Mapics. Tout le reste du système fonctionne pendant et après la migration.

C’est la différence entre une intégration point-à-point (fragile, difficile à faire évoluer) et une architecture hub (stable, extensible, maintenable).

Par où commencer

Vous n’avez pas besoin de connecter cinq systèmes le premier jour. Commencez par un.

Quel est le système dont vos équipes ont le plus souvent besoin de données? Quel est le workflow où la friction est la plus grande — où les gens exportent des données dans Excel pour faire quelque chose que le système ne sait pas faire?

Commencez là. Construisez un connecteur. Exposez quelques fonctions utiles. Voyez ce que ça change. Le hub grandit naturellement à partir de là.

Ce qui fonctionne dans votre usine depuis 20 ans n’a pas besoin d’être remplacé pour être amélioré.