Maturité IA d’un groupe sur son ERP : les décisions à prendre avant de brancher quoi que ce soit

Dans un groupe multi-entités, la maturité IA n’est ni une note de culture ni un inventaire d’outils. C’est une courte liste de décisions, chacune avec un responsable : les entités enregistrent-elles la même chose de la même façon, que peut lire l’IA, que peut-elle écrire et sous quel nom, où les données peuvent-elles être traitées, et comment une mauvaise réponse sera-t-elle repérée. Tant que ces décisions ne sont pas prises, toute IA que vous branchez lit vos incohérences et les répète avec assurance.

Pourquoi les diagnostics de maturité IA classiques passent-ils à côté dans un groupe ?

Parce qu’ils notent l’organisation d’un seul bloc : stratégie, compétences, culture, infrastructure. Dans une société unique, c’est une image honnête. Dans un groupe, l’écart qui compte se situe entre les entités. Le même mot désigne deux choses dans deux filiales, et personne ne s’en aperçoit avant qu’un état doive les additionner.

Business Central le rend concret. Les axes analytiques principaux sont définis par société : chacune choisit ses deux axes principaux et jusqu’à huit raccourcis d’axe sur la page Paramètres comptabilité. Cinq filiales peuvent donc, en toute légitimité, faire tourner cinq schémas analytiques différents. Et Microsoft prévient que changer un axe principal après coup oblige à mettre à jour toutes les écritures validées avec cet axe, ce qui peut prendre du temps, peser sur les performances et verrouiller des tables. Le moment où il coûte le moins d’aligner la façon dont les entités enregistrent, c’est avant de construire par-dessus, pas après.

Une couche d’IA est une construction de plus par-dessus. Un diagnostic qui ne regarde pas cet écart note la mauvaise chose.

Vos entités enregistrent-elles la même chose de la même façon ?

C’est la première décision, et elle se joue sur deux plans.

Les comptes. Business Central sait consolider des sociétés dont les plans comptables diffèrent, mais seulement une fois que quelqu’un a rattaché chaque compte de chaque filiale à un compte de la société de consolidation, via les champs de compte de consolidation au débit et au crédit. Les sections analytiques se rattachent de la même façon, par un code de consolidation. Ce rattachement est ce qui ressemble le plus, dans un groupe, à un vocabulaire commun. S’il n’existe pas, ou s’il n’existe que pour la consolidation annuelle, une IA interrogée sur une marge groupe n’a aucune règle à suivre. Décidez quel rattachement fait référence, et qui en est responsable.

Les données de référence. Clients, fournisseurs, articles : partagés entre entités ou propres à chacune ? Business Central peut synchroniser les données de référence d’une société source vers des filiales, et Microsoft en fixe précisément les limites : les filiales tirent les données depuis la source, toutes les sociétés doivent être dans le même environnement, seules les tables non transactionnelles doivent être synchronisées, et Microsoft déconseille de synchroniser dans les deux sens à cause des conflits et des écrasements. Si le même client existe sous trois numéros dans trois entités, une IA interrogée sur l’exposition du groupe à ce client répondra pour un seul d’entre eux. Décidez la source de chaque table de référence, et qui en est responsable.

Que peut lire l’IA, et que peut-elle écrire ?

Décidez-le cas d’usage par cas d’usage, pas une fois pour tout le groupe.

Sur Business Central, la manière standard de brancher une IA est le serveur MCP, et ses configurations décident quelles pages et requêtes d’API sont exposées et quelles opérations chacune autorise. La documentation de Microsoft indique que la configuration par défaut intégrée donne un accès en lecture seule aux pages et requêtes d’API éligibles que l’utilisateur connecté a le droit d’utiliser. Créer, modifier, supprimer et lancer des actions doivent être activés explicitement, configuration par configuration.

Un groupe a donc trois décisions à écrire avant de mettre un agent en service :

1. Quelles données lit chaque cas d’usage. Une configuration par famille de questions, pas une configuration qui voit tout.
2. S’il écrit, et où. S’il écrit, c’est dans une zone d’attente, avec une action délibérée pour valider, jamais directement dans les données validées.
3. Sous quel nom. Chaque appel s’exécute avec l’identité et les droits de l’utilisateur connecté. Aucun compte IA partagé : chaque modification porte le nom d’une personne.

La façon dont ces choix tiennent devant un auditeur est traitée dans notre article sur la gouvernance de l’IA en finance.

Où vos données peuvent-elles être traitées ?

Cette question est souvent laissée à la DSI, et elle ne devrait pas l’être. C’est une décision pour la personne qui répond de la protection des données dans le groupe.

Pour les fonctionnalités Copilot et agents propres à Business Central, Microsoft utilise des ressources Azure OpenAI qu’il gère lui-même. Pour les environnements hébergés en France ou ailleurs en Europe, le traitement peut avoir lieu dans plusieurs zones géographiques à l’intérieur de l’EU Data Boundary, et le réglage qui autorise ce déplacement des données, sur la page des fonctionnalités Copilot et agents, est activé par défaut. Le désactiver rend les fonctionnalités concernées indisponibles. Microsoft précise aussi que les fonctions d’IA ajoutées par d’autres éditeurs, via des extensions ou des applications de la marketplace, définissent leurs propres régions de traitement, et renvoie vers l’éditeur pour le détail. Enfin, ce réglage ne couvre pas Microsoft Copilot dans Business Central, l’expérience disponible à partir de la version 29, qui relève des engagements de Microsoft 365 Copilot.

La question de maturité n’est donc pas seulement « Copilot ou pas ». C’est : pour chaque modèle que vous comptez utiliser, où les données sont-elles traitées, et qui l’a validé ? Un modèle non Microsoft branché par MCP arrive avec les conditions de son propre fournisseur, qui demandent la même lecture attentive.

Par quel cas d’usage commencer ?

Par un contrôle que l’équipe fait déjà à la main et sait décrire précisément. Quel état, quel filtre, quelle tolérance, ce qui compte comme une anomalie. Si personne ne sait énoncer la règle, aucun modèle ne peut l’appliquer, et personne ne pourra dire s’il l’a bien appliquée.

Les contrôles de fin de mois sont un bon candidat dans la plupart des groupes, parce qu’ils reviennent à chaque période avec les mêmes règles. Nous détaillons les tâches de clôture qu’un modèle peut préparer, et celles qui doivent rester humaines, dans notre article sur l’IA dans la clôture mensuelle.

L’inverse est vrai aussi. Un cas d’usage qui dépend d’une décision que personne n’a prise, par exemple savoir quelle entité a raison quand deux soldes intersociétés divergent, n’est pas encore un cas d’usage IA. C’est une décision qui attend un responsable.

Comment saurez-vous que l’IA se trompe ?

Décidez-le avant la première réponse. Deux mécanismes comptent :

• Une seconde voie pour chaque chiffre. Un agent qui filtre sur le mauvais champ annonce « rien trouvé » avec une assurance totale. Chaque résultat qu’il rend est comparé à un chiffre obtenu autrement avant que quiconque agisse.
• Une trace de ce que l’agent a fait. À partir de la version 28.0, la télémétrie de Business Central enregistre chaque appel d’outil MCP, avec l’utilisateur, l’outil, la configuration et le client à l’origine de l’appel. Les modifications des configurations MCP sont enregistrées aussi.

Et un dernier responsable : qui peut tout arrêter. Dans Business Central, les administrateurs peuvent désactiver une à une les fonctionnalités Copilot et agents, et accorder ou refuser l’accès utilisateur par utilisateur. Nommez la personne qui le fera, et sur quel signal.

À quoi ressemble une réponse de maturité ?

Pas à une note sur cinq. À un tableau de décisions : la question, si elle est tranchée, qui en est responsable, et pour quand. Rattachement commun des comptes, source des données de référence, périmètre de lecture et d’écriture par cas d’usage, utilisateurs nommés, lieu de traitement par modèle, vérification et arrêt.

Parfois, la réponse honnête est qu’il faut corriger les données avant qu’une IA s’en approche. C’est quand même une réponse utile : elle dit au comité de direction quoi financer en premier.

L’approche Asio Services

Nous traitons la maturité IA comme un travail de cause racine appliqué à l’IA : repérer les décisions qui n’ont pas été prises et qu’un modèle reprendrait telles quelles, nommer un responsable pour chacune, et seulement ensuite choisir le premier cas d’usage. C’est ainsi que nous abordons l’IA pour les groupes multi-entités : Copilot quand il convient, un autre modèle quand il convient mieux, les mêmes règles en dessous. Si votre comité vous demande un plan IA et que vous n’êtes pas sûr que vos entités soient prêtes, commencez par le formulaire clarté.

FAQ

Qu’est-ce qu’un diagnostic de maturité IA pour un ERP ?

Un examen de la capacité de vos données et de vos règles ERP à porter de l’IA, avant de brancher quoi que ce soit. Dans un groupe, il porte sur des décisions : rattachement commun des comptes, responsabilité des données de référence, ce que l’IA peut lire et écrire, sous quel nom, où les données sont traitées et comment les erreurs sont repérées.

Faut-il des données parfaites avant d’utiliser l’IA sur notre ERP ?

Non. Mais l’IA lit les données telles qu’elles sont. Si les entités enregistrent la même chose de façons différentes, le modèle reproduit l’écart. Le diagnostic vous dit quels écarts comptent pour le cas d’usage que vous visez.

L’IA sur Business Central est-elle en lecture seule par défaut ?

Via le serveur MCP de Business Central, oui. La configuration par défaut intégrée donne un accès en lecture seule aux pages et requêtes d’API éligibles que l’utilisateur connecté peut utiliser. L’écriture doit être activée explicitement dans une configuration.

Qui doit porter la maturité IA dans un groupe ?

Pas la DSI seule. La finance porte le rattachement des comptes et les contrôles, les opérations portent les données de référence, et la personne qui répond de la protection des données valide le lieu de traitement. Chaque décision a besoin d’un responsable nommé.