Votre IA n'est pas un abonnement, c'est un système d'information

En 2026, Mistral ne se présente plus comme le laboratoire qui construit le meilleur modèle européen. L'entreprise vend du déploiement, de la personnalisation sur données client et de l'infrastructure — environ 400 millions de dollars de revenus annualisés début 2026, vingt fois l'année précédente, portés par les entreprises et non par le grand public. Et en février 2026, elle a signé un partenariat pluriannuel avec Accenture. Quand un éditeur de modèles s'adosse à un intégrateur, il dit une chose simple : le modèle seul ne suffit pas.

Il faut retourner l'exemple jusqu'au bout. Si le champion européen des modèles a besoin d'Accenture, c'est que même un éditeur ne peut pas faire l'intégration à la place de son client. Le modèle est devenu un composant que n'importe qui appelle en trois lignes de code. Ce qui reste difficile, c'est le système autour — et ce système, c'est le vôtre. Une entreprise de trente personnes vit ce déplacement autant qu'un groupe du CAC 40, à son échelle.

Pourquoi l'IA n'est plus un sujet d'outil mais un sujet de système d'information

Un modèle de langage ne produit de valeur qu'au contact des données de votre entreprise. Seul, il connaît le monde ; il ne connaît ni vos clients, ni vos tarifs, ni vos procédures, ni l'historique de votre dernier litige fournisseur. Or dans une entreprise qui compte plusieurs services, ces informations sont dispersées : une partie dans l'ERP, une partie dans les boîtes mail, une partie dans les fichiers partagés de chaque service, une partie dans des documents scannés, et une partie dans les têtes.

Brancher une IA sur ce paysage suppose donc trois choses qu'aucun abonnement ne fournit : aller chercher les données là où elles vivent ou les constituer quand elles n'existent pas sous forme exploitable, les rendre interrogeables sans casser les droits de chaque service, et encadrer ce que la machine est autorisée à faire avec. Ce sont trois chantiers d'ingénierie logicielle. Pas trois modules de formation.

Le bon moment, c'est le choix de l'ERP — donc une dizaine de salariés

Une entreprise structure son système d'information au moment où elle atteint une dizaine de personnes réparties en plusieurs services : c'est là qu'elle choisit son ERP, son outil de gestion commerciale, sa GED. Ce choix décide pour dix ans de ce que l'intelligence artificielle pourra faire chez elle. Un éditeur dont les données sortent par une interface programmable ouvre toutes les portes ; un éditeur qui garde les développements chez lui plafonne d'avance chaque projet, quel que soit le budget qu'on y mettra ensuite.

C'est la raison pour laquelle nous parlons d'IA à des dirigeants d'entreprises de quinze personnes. Pas parce qu'ils sont prêts à déployer des agents, mais parce qu'ils sont en train de prendre une décision structurante sans savoir qu'elle est structurante. Un système d'information dont les données ne peuvent pas être reliées — aux autres applications aujourd'hui, aux modèles de langage demain via un serveur MCP — n'est pas un système ralenti : c'est un système enfermé.

Voici les six critères à exiger d'un éditeur avant de signer. Ils ne coûtent rien à demander, et ils valent diagnostic : un éditeur qui esquive les trois premiers vous dit déjà ce que sera la suite.

• Une API documentée, en lecture et en écriture. La lecture seule suffit pour un tableau de bord ; elle interdit toute automatisation qui agit. Exiger le périmètre d'écriture par écrit.
• Un périmètre fonctionnel explicite. Quelles entités sont exposées — clients, commandes, stocks, comptabilité, production — et lesquelles ne le sont pas. Une API qui ne couvre que le CRM ne vous servira pas côté atelier.
• Une trajectoire tarifaire. Le coût d'accès aujourd'hui, et son évolution avec les volumes. Un tarif au palier qui double à chaque seuil rend impossible tout usage à grande échelle.
• Une documentation publique et un espace développeur. Si l'intégration doit obligatoirement passer par les équipes de l'éditeur, vous ne maîtrisez ni les délais, ni les coûts, ni la priorisation.
• Une connectabilité aux modèles de langage. Un serveur MCP natif, disponible ou inscrit à la feuille de route avec une échéance. C'est ce qui permettra à une IA d'interroger votre gestion sans qu'on recode un connecteur à chaque fois.
• Une réversibilité des données. Un export complet, dans un format ouvert, à tout moment et sans facturation punitive. Vos données sont votre actif : elles doivent pouvoir partir avec vous.

Ouvrir des comptes ChatGPT, et former à les utiliser, ne constitue pas une politique IA

Un abonnement donne accès à un modèle. Une formation apprend à s'en servir. Les deux sont nécessaires, et nous animons nous-mêmes ces sessions d'acculturation : sans elles, les outils restent dans un coin et personne ne s'en sert. Mais ni l'un ni l'autre ne donne accès à vos données métier, ni traçabilité des usages, ni cadre de responsabilité.

Lors d'un audit mené en 2026 chez un industriel d'environ 150 personnes réparties en une dizaine de services, nous avons mesuré qu'environ trois quarts des collaborateurs utilisaient déjà l'intelligence artificielle. Presque tous sur des comptes personnels, souvent gratuits, avec des données internes dans les prompts. Personne n'avait besoin d'apprendre à se servir d'un modèle : la compétence d'usage était là depuis longtemps. Ce qui manquait, c'était le système autour.

C'est le point aveugle de beaucoup d'accompagnements : deux métiers différents portent le même nom. L'expert de l'usage part du modèle et de son interface ; le professionnel du système d'information part de vos applications et de vos données. Le premier demande quels usages vous voulez améliorer ; le second demande où vit chaque information et qui a le droit de la lire. La différence se voit au bout de six mois.

• Ce que produit l'expert de l'usage : une montée en compétence, une charte, une bibliothèque de prompts. Le gain se compte en heures gagnées par personne, et il repart avec les personnes.
• Ce que produit le professionnel du SI : des connecteurs, un index segmenté par rôle, des journaux, des tests, une exploitation. Le gain se compte en processus dont le coût change, et il reste dans l'entreprise.
• La frontière entre services : le premier ne la franchit pas, chacun travaille dans son coin. Le second n'a que ça comme objet — croiser les données sans casser les droits.

La formation est la couche visible d'une stratégie IA. Elle n'en est pas le socle. Et confondre les deux coûte cher : les équipes sont formées, le budget est consommé, et l'entreprise se retrouve six mois plus tard sans données reliées, sans droits découpés et sans personne dont ce soit la responsabilité.

Une politique IA multi-services, à quoi ça ressemble concrètement

Une politique IA qui tient se lit comme un tableau. Pour chaque service, elle précise quatre choses : les cas d'usage autorisés, les données mobilisables, le niveau d'autonomie accordé à la machine, et la personne qui répond du résultat. Ce qui n'est pas dans le tableau n'est pas autorisé. Voici à quoi ressemblent quelques lignes, volontairement génériques.

• Support client — brouillon de réponse et qualification, sur la base de connaissance et l'historique du ticket, avec validation humaine avant envoi. Responsable : le responsable du support.
• Administration des ventes — saisie de commande depuis un bon reçu, sur le catalogue, les tarifs et le compte client, en écriture encadrée avec journal et retour arrière. Responsable : le responsable ADV.
• Finance — détection d'anomalies de facturation sur les écritures et le référentiel fournisseurs, en proposition soumise à validation. Responsable : le directeur administratif et financier.
• Production et qualité — recherche documentaire et rédaction de comptes rendus en autonomie ; en revanche, décision de conformité ou libération de lot strictement interdites à la machine. Responsable : le responsable qualité.
• Ressources humaines — rédaction d'offres et synthèses, sur documents non nominatifs uniquement, en autonomie. Responsable : le directeur des ressources humaines.

La colonne qu'on oublie toujours est la dernière : le responsable. C'est elle qui rend le tableau opposable, parce qu'elle transforme une intention en engagement. Et c'est ce document qu'aucun expert de l'usage ne peut produire seul : il faut connaître les données autant que les métiers, puisque chaque ligne se traduit ensuite en configuration réelle — quels index, quels droits, quelles limites.

Rendre vos données interrogeables, mais par rôle

Un RAG bien construit ne cherche pas dans « tous les documents de l'entreprise » pour masquer ensuite ce que l'utilisateur n'a pas le droit de voir. Il ne récupère que ce que le demandeur peut lire, service par service, rôle par rôle. La nuance est technique et elle est essentielle : filtrer à l'affichage est une faille, pas une permission. Le contrôle d'accès doit vivre dans l'index lui-même, et chaque récupération doit être journalisée comme un accès.

Encore faut-il que les données soient atteignables. Chez l'industriel évoqué plus haut, la direction voulait une interface de chat unique branchée sur l'ensemble de l'entreprise. Le diagnostic a été qu'aucun usage transverse n'était possible à ce stade, pour une raison antérieure à l'IA : les données existaient en entier, mais aucun système ne les reliait. L'ERP connaissait l'ordre de fabrication sans le numéro de série, l'application de suivi connaissait la machine sans la facturation, et une partie de la traçabilité ne vivait que sur papier.

« C'était moins un problème d'intelligence artificielle qu'un problème de logiciel. »

Le symptôme se voyait partout : six à sept fichiers Excel parallèles dans un seul service, treize ans de recopie manuelle ligne à ligne. Des humains faisaient à la main les jointures que les logiciels ne faisaient pas entre eux. Aucun modèle, aussi bon soit-il, ne corrige cela — c'est un travail d'intégration, et il se fait avant.

L'agentique change la nature du risque

Un assistant se trompe dans une réponse ; un agent se trompe dans une action. Dès qu'un système écrit dans l'ERP, envoie un courriel à un client ou engage une dépense, l'erreur ne se lit plus avant, elle se constate après. Le niveau d'autonomie accordé à la machine ne peut donc pas se décider une fois pour toute l'entreprise : il se règle tâche par tâche, sur la gravité de l'erreur possible.

• Autonome — documentation, résumés, traductions, classement. L'erreur est visible immédiatement et ne coûte rien.
• Proposé, validé — brouillon de réponse client, pré-remplissage, devis. La machine prépare, l'humain envoie.
• Écriture encadrée — mise à jour d'un système, avec journal, quota, périmètre restreint et retour arrière possible.
• Humain exclusivement — qualité, conformité, engagement contractuel, décision touchant une personne. La machine documente, elle ne décide pas.

Deux règles accompagnent cette échelle. D'abord, une tâche ne monte de niveau que sur preuve : un historique propre et un jeu de tests qui tient, jamais l'enthousiasme d'un pilote réussi. Ensuite, une limite dure s'impose hors du modèle — dans le code, dans les droits, dans les quotas. Une consigne écrite dans un prompt est une suggestion, pas une garantie.

Reste le risque le plus discret : la dérive silencieuse. Un système qui répondait correctement en janvier peut se dégrader en juin — le modèle a changé de version, les données ont évolué, quelqu'un a modifié une instruction. Sans jeu de cas de référence exécuté en continu, la baisse de qualité se découvre par la plainte d'un client.

Auditable et vérifiable : la conséquence, pas l'objectif

On n'ajoute pas l'auditabilité à un système : on la constate sur un système bien construit. Quand les droits vivent dans l'index, les accès sont journalisés par construction. Quand la récupération trace ses sources, les réponses s'expliquent. Quand les modèles, les instructions et les données sont versionnés, une décision prise il y a six mois se rejoue à l'identique. Et quand un jeu de tests tourne en continu, la dérive se voit avant l'utilisateur.

C'est pourquoi l'auditabilité n'est pas un objectif que l'on se fixe en fin de projet : c'est le sous-produit d'un travail d'ingénierie fait correctement. Elle se dose d'ailleurs comme le reste — une tâche de niveau autonome n'a pas besoin de rejeu, une écriture encadrée ne s'ouvre pas sans lui. Et dans un secteur réglementé, une contribution machine non identifiée dans un dossier est un problème d'audit avant d'être un problème de qualité : ce que l'IA a produit doit être tracé comme tel.

Ce que vous pouvez faire sans nous, et qui compte vraiment

Quatre décisions structurent une stratégie IA sans qu'aucune ne nécessite de prestataire. Elles relèvent de l'organisation, et elles valent souvent plus que le premier chantier technique.

• Ouvrir des comptes professionnels aux collaborateurs qui utilisent déjà l'IA quotidiennement. Un compte entreprise sort les usages des comptes personnels, protège vos données, et coûte moins cher que la première heure gagnée dans le mois.
• Écrire la liste des outils autorisés. Une page suffit. Sans elle, chacun choisit le sien et vos informations circulent chez des éditeurs que vous n'avez jamais évalués.
• Désigner la personne qui sait où vit chaque information. C'est un rôle, pas un poste à créer : quelqu'un capable de dire dans quel système se trouve une donnée et comment elle devrait circuler. Sans ce rôle, tout projet reste orphelin.
• Mesurer un indicateur par service avant de déployer. Le temps de traitement d'un dossier, le délai de réponse, le nombre de ressaisies. Sans mesure avant, vous n'aurez jamais de preuve après.

Pourquoi des professionnels du système d'information, et pas des experts de l'usage

Parce qu'une politique IA n'existe que si quelqu'un l'écrit dans le code. Le niveau d'autonomie d'un agent est une ligne de configuration, pas une phrase dans un document. La segmentation par service est une contrainte d'indexation. La traçabilité est un journal et un versionnage. La détection de dérive est une suite de tests exécutée par une intégration continue. Un support de présentation ne contraint rien, et une bibliothèque de prompts ne relie aucune donnée.

Les Entrecodeurs abordent ces projets par le système d'information : nous commençons par cartographier où vivent vos données et qui a le droit de les lire, avant de parler de modèles. Nous construisons les connecteurs, les index segmentés, les garde-fous et les tests qui font qu'un système reste vérifiable dans la durée. Et quand le préalable manque — un ERP fermé, des données non reliées — nous le disons avant d'engager un chantier plutôt qu'au milieu.

Si vous êtes en train de choisir votre ERP, ou si vos équipes utilisent déjà l'IA sans cadre, ces deux situations sont le bon moment pour en parler. Découvrez notre approche de l'intelligence artificielle en entreprise, ou écrivez-nous pour un premier échange — nous vous dirons franchement si le sujet est mûr chez vous.