Données ERP/CRM : reprendre la main avant de parler d'IA souveraine

# Données ERP/CRM : reprendre la main avant de parler d'IA souveraine

*En 2026, le discours sur l'IA en entreprise a atteint sa vitesse de croisière. Mais dans les PME et ETI européennes, le vrai frein n'est pas le modèle de langage — c'est la gouvernance des données qui l'alimente. Nous avons interrogé un DSI d'une ETI industrielle française (600 salariés, déployée sur quatre pays européens), qui a engagé depuis dix-huit mois une refonte complète de son architecture de données ERP/CRM. Sans nom, sans titre ronflant : juste un retour d'expérience direct.*

RiffLab Media : On entend beaucoup parler d'IA souveraine. Mais concrètement, dans votre quotidien de DSI, c'est quoi le premier obstacle ?

L'obstacle, c'est que la plupart des directions générales ont signé des contrats IA avant de regarder dans quel état étaient leurs données. Moi le premier, j'ai failli tomber dans ce piège. On vous vend une promesse — «branchez l'IA sur votre CRM, votre ERP, et tout devient intelligent» — et vous réalisez trois mois plus tard que vos données clients sont éparpillées entre cinq référentiels, que vos champs d'adresse ne sont pas normalisés de la même façon selon les pays, et que personne ne sait vraiment qui est propriétaire de quel objet de données dans l'organisation.

L'IA souveraine, ça commence là. Pas dans le choix du modèle. Dans la capacité à dire : «ces données m'appartiennent, je sais ce qu'elles contiennent, je contrôle qui y accède et pourquoi.» Tant que vous n'avez pas ça, vous pouvez choisir le fournisseur le plus souverain d'Europe, vous allez quand même lui livrer un bazar.

Vous parlez de propriété des données. Mais dans une ETI avec un ERP historique et un CRM qui a grandi organiquement, comment vous posez concrètement la question de la gouvernance ?

On a commencé par quelque chose d'apparemment simple mais politiquement compliqué : nommer des data owners métier. Pas des data stewards techniques — des responsables métier, avec une fiche de mission, qui signent sur la qualité et la définition de leurs objets de données.

Prenez l'objet «client» dans notre CRM. Qui en est propriétaire ? La direction commerciale ? La direction financière qui gère les contrats ? Le service ADV qui traite les commandes ? Chez nous, la réponse n'était pas claire. Et cette ambiguïté, c'est exactement ce que les acteurs dominants US exploitent : quand personne en interne ne «possède» vraiment la donnée, c'est le prestataire ou l'éditeur qui devient de facto le seul à s'y retrouver. Vous devenez dépendant de son support, de ses exports, de sa roadmap.

Nommer des data owners, c'est un acte de souveraineté organisationnelle avant d'être un acte technique.

Ça implique des recrutements, des formations ? Quelles compétences vous avez cherché à internaliser plutôt qu'à sous-traiter ?

On a fait un choix délibéré de ne pas externaliser la fonction de gouvernance des données. Pas l'outillage — l'outillage on peut s'appuyer sur des partenaires — mais la compétence de définition des règles, des politiques, des processus de qualité : ça reste en interne.

Concrètement, j'ai monté une cellule de trois personnes. Un profil data engineer avec une sensibilité métier, capable de dialoguer aussi bien avec la DSI qu'avec un directeur commercial. Un profil juriste-data, parce qu'en 2026 dissocier gouvernance des données et conformité réglementaire européenne — RGPD, Data Act, AI Act — c'est une faute de gestion. Et un profil que j'appelle «traducteur métier-data» : quelqu'un qui sort des réunions métier avec une compréhension fine de ce que les gens font réellement avec les données, pas ce qu'ils disent faire.

Ce qui est interdit dans ma roadmap RH : que cette compétence soit portée uniquement par un intégrateur externe, fût-il européen. Le jour où le contrat s'arrête, vous ne savez plus pourquoi vos règles de gestion existent.

Les éditeurs ERP/CRM, y compris européens, poussent leurs propres couches IA. Comment vous évitez de recréer une dépendance, même avec un acteur qui se présente comme souverain ?

La question que je pose systématiquement à tout éditeur, européen ou pas : «Si demain je veux changer de solution, dans quel format j'exporte mes données, avec quelle granularité, et sous quel délai ?» La réponse à cette question seule vous dit si vous allez vers une dépendance ou vers une vraie relation de partenariat.

J'ai travaillé avec un éditeur ERP européen — je ne citerai pas de nom ici — dont la couche IA était prometteuse sur le papier. Mais leurs modèles s'entraînaient sur des données agrégées cross-clients hébergées dans des conditions contractuelles floues. Dès que vous posez la question «où vont mes données d'entraînement», vous voyez si l'éditeur a vraiment réfléchi à la souveraineté ou si c'est un argument marketing.

La gouvernance interne que j'ai mise en place me protège de ça : avant tout nouveau module IA, on fait une analyse d'impact sur les flux de données. Qui envoie quoi, où, dans quelles conditions. C'est devenu un processus standard, pas une exception.

Parlons du CRM spécifiquement. C'est souvent le maillon faible côté données commerciales. Comment vous avez sécurisé cet actif ?

Le CRM, c'est l'endroit où la donnée est la plus volatile et la plus stratégique à la fois. Volatile parce que les commerciaux saisissent ce qu'ils veulent, quand ils veulent, avec les libellés qu'ils inventent. Stratégique parce que c'est là que réside votre connaissance client, votre historique de relation, vos signaux faibles commerciaux.

On a construit ce qu'on appelle un «référentiel tiers maître» — une base canonique de nos clients, prospects et partenaires, hébergée sur notre infrastructure, qui fait office de source de vérité pour tous les systèmes. Le CRM se synchronise sur ce référentiel, il ne le crée pas. Cette inversion semble anodine, mais elle change tout : si demain je change de CRM, mon référentiel client reste. Je ne pars pas de zéro.

Et ce référentiel, il est documenté, versionné, avec des règles de gestion écrites par les data owners métier que j'évoquais. Pas dans la tête d'un consultant qui ne travaille plus pour nous.

Dernier mot : pour un DSI d'ETI qui se dit «je veux démarrer une démarche IA souveraine sur mon ERP/CRM», par quoi il commence la semaine prochaine ?

Par un audit honnête, interne, sans prestataire externe. Trois questions seulement.

Première question : si mon éditeur principal disparaît demain, combien de temps me faudrait-il pour récupérer mes données dans un format exploitable ? Si vous ne savez pas répondre en moins de trente secondes, vous avez un problème de souveraineté.

Deuxième question : est-ce que j'ai, en interne, une personne qui peut expliquer à un nouvel arrivant les règles de gestion de mes objets de données clés — client, produit, contrat — sans avoir besoin de consulter un prestataire ? Sinon, la compétence est sortie de l'organisation.

Troisième question : est-ce que mes données ERP/CRM sont dans un état tel que je pourrais les soumettre à un modèle IA sans avoir honte du résultat ? Pas parfait — personne n'a des données parfaites. Mais structuré, cohérent, documenté.

Si vous répondez non à deux de ces trois questions, ne parlez pas encore d'IA souveraine. Parlez de fondation. L'IA vient après.

*ETI industrielle française, 600 salariés, présente dans quatre pays européens. La démarche de gouvernance des données décrite est en cours depuis dix-huit mois.*