IA en entreprise : le vrai blocage n'est pas le modèle, c'est l'accès à vos données

Vous avez vu la démo. Quelqu'un a branché un modèle sur trois documents, posé une question, obtenu une réponse propre. Tout le monde dans la salle s'est dit que le sujet était réglé. Six semaines plus tard, le projet est à l'arrêt, et personne ne sait vraiment dire pourquoi. La technologie marchait pourtant, en démo.

Ce moment, je le vois revenir sur presque chaque projet IA d'entreprise. Le malentendu est toujours le même : on croit que le travail consiste à choisir le bon modèle. En réalité, le modèle est devenu la partie facile. Le vrai chantier, celui que la démo masque, c'est l'accès à vos données.

Pourquoi le modèle n'est plus le problème

Il y a deux ans, le choix du modèle pesait lourd. Les écarts de qualité entre deux fournisseurs étaient visibles à l'œil nu, et un mauvais choix pouvait condamner un cas d'usage. Ce n'est plus la situation.

Les modèles généralistes actuels savent résumer, classer, extraire, reformuler et répondre à un niveau largement suffisant pour la majorité des besoins d'une entreprise. La différence entre deux fournisseurs sérieux ne se voit plus sur vos cas réels, elle se mesure sur des classements techniques qui ne ressemblent pas à votre quotidien.

Conséquence directe : quand un projet IA échoue, ce n'est presque jamais parce que le modèle n'était pas assez bon. C'est parce qu'on lui a donné les mauvaises données, des données sales, ou aucune donnée fiable du tout. Le modèle répond toujours quelque chose. S'il répond à côté, regardez d'abord ce que vous lui avez donné à lire.

Là où les projets calent vraiment

La démo réussit parce qu'elle triche, sans mauvaise intention. On choisit trois documents propres, récents, bien écrits. On pose une question dont on connaît la réponse. Tout fonctionne. Le passage à l'échelle révèle ce que la démo avait évité.

Première rupture : le volume. Trois documents deviennent trois mille, répartis sur un serveur de fichiers, une messagerie, un outil métier et deux tableurs que personne n'ouvre plus. Le modèle ne sait pas où chercher, parce que personne ne lui a dit où était la vérité.

Deuxième rupture : l'état des données. Vos documents internes sont contradictoires. Trois versions d'une même procédure cohabitent, deux tarifs différents traînent dans deux fichiers, la dernière mise à jour date d'un départ il y a un an. Le modèle ne tranche pas, il restitue le désordre que vous lui donnez.

Troisième rupture : les droits. Dès que l'outil sort du périmètre d'une seule personne, la question des accès explose. Qui a le droit de voir quoi ? Un assistant IA qui répond à tout le monde avec les données RH ou commerciales de toute l'entreprise n'est pas un gain de productivité, c'est un incident en attente.

Les quatre couches d'un projet IA, du plus visible au plus déterminant

La démo se joue sur les deux premières lignes. Le projet réel se gagne ou se perd sur les deux dernières. C'est exactement l'inverse de l'attention qu'on leur accorde au départ.

Comment cadrer l'accès aux données avant de brancher l'IA

La bonne nouvelle, c'est que ce travail se cadre. Il ne demande pas une refonte de votre système d'information, il demande de répondre à quelques questions précises avant d'écrire la première ligne de code. C'est le cœur de la phase Scan de la méthode S3.

Quelle source fait référence pour chaque information. Pour le cas d'usage visé, listez les informations dont le modèle a besoin, et pour chacune, désignez un seul endroit qui fait foi. Si deux systèmes portent le prix d'un produit, décidez lequel gagne. Cette décision-là vaut plus que le choix du modèle.

Dans quel état sont ces sources. Avant d'automatiser, regardez la réalité : doublons, versions périmées, formats illisibles, champs vides. Un nettoyage ciblé sur les seules données du cas d'usage suffit souvent. Inutile de ranger toute l'entreprise pour démarrer un projet précis.

Qui a le droit de voir quoi. Définissez les périmètres d'accès avant de connecter quoi que ce soit. L'outil doit respecter les droits existants de chaque utilisateur, pas les contourner au nom de la fluidité.

Qui en répond dans le temps. Une source de données vit. Quelqu'un doit rester responsable de sa fraîcheur et de sa qualité une fois le projet en production, sinon l'outil se dégrade en silence et personne ne s'en aperçoit avant la première mauvaise réponse devant un client.

L'erreur qui coûte le plus cher

L'erreur classique consiste à changer de modèle quand le projet déçoit. On passe d'un fournisseur à l'autre en espérant que le suivant comprendra mieux. Le résultat ne bouge pas, parce que le problème n'a jamais été là.

Tant que vos données sont dispersées, contradictoires et sans propriétaire clair, le meilleur modèle du monde restituera fidèlement votre désordre. L'inverse est vrai aussi : une fois l'accès aux données cadré, même un modèle modeste produit des résultats que vos équipes utilisent vraiment. Le levier n'est pas dans le moteur, il est dans ce que vous lui donnez à lire.

Questions fréquentes

Faut-il un grand projet de gouvernance des données avant de faire de l'IA ? Non. C'est même le meilleur moyen de ne jamais démarrer. Le cadrage se fait au périmètre du cas d'usage, pas à l'échelle de toute l'entreprise. Vous préparez les données dont ce projet précis a besoin, rien de plus, et vous élargissez ensuite si le cas suivant le justifie.

Comment savoir si mes données sont prêtes pour l'IA ? Posez-vous la question des sources qui font référence. Si, pour chaque information utile au cas d'usage, vous pouvez désigner un seul endroit à jour et fiable, vous êtes prêt. Sinon, vous savez déjà ce qu'il reste à faire avant de brancher le modèle.

Le choix du modèle n'a donc aucune importance ? Il en a, mais bien moins qu'on ne le croit, et plus tard dans la réflexion. Commencez par un modèle généraliste sérieux, concentrez l'effort sur l'accès aux données, et ne revenez sur le choix du modèle que si un besoin précis le justifie, par exemple une contrainte de souveraineté ou de coût.

Combien de temps pour cadrer cet accès ? Sur un cas d'usage bien délimité, le diagnostic se mène en quelques jours, pas en quelques mois. L'objectif de la phase Scan est précisément de livrer ce cadrage sous 48h après un premier audit, pour savoir si le projet tient debout avant d'engager le moindre développement.