Un rapport d'audit IA, en entier, sur une entreprise qui n'existe pas

La direction du distributeur a posé la question dans ces termes : « Tout le monde parle d'IA : où ça sert vraiment ici, et par quoi commencer ? » Telle quelle, cette question n'a pas de réponse, parce qu'elle porte sur une technologie et pas sur un travail. Je l'ai donc réécrite en question auditable, c'est-à-dire en question à laquelle quatre jours de travail peuvent répondre. La voici : parmi les usages que vos équipes citent spontanément, lesquels tiennent devant les données qui existent réellement aujourd'hui, pour quel effort, et dans quel ordre les prendre ?

Pendant ces quatre jours, j'ai conduit 11 entretiens, du dirigeant au magasinier, et 3 observations de poste en ADV, l'administration des ventes. Un entretien vous dit ce que les gens croient faire, une observation montre les gestes qu'ils ne pensent plus à raconter : les reprises de saisie, les allers et retours entre deux écrans, les vérifications qui ne figurent dans aucune procédure. J'ai aussi repris 2 exports de l'ERP sur 12 mois et échantillonné 400 documents au hasard.

Le quatrième jour n'ajoute aucune matière, il sert à chiffrer l'effort et à mettre les cinq pistes dans un ordre. La restitution se fait devant les personnes que j'ai interrogées, et c'est le seul filtre qui compte : si une phrase du rapport ne tient pas devant celui qui fait le travail tous les jours, elle saute. Le cadre général est décrit dans ma méthode.

Ce que cet audit ne dit pas

• Ce n'est pas un audit de sécurité : je regarde où sont les données, pas si elles sont correctement protégées.
• Ce n'est pas une revue du code de l'ERP : je prends le système tel qu'il tourne, sans juger la façon dont il est écrit.
• Ce n'est pas un test utilisateur : trois observations montrent des gestes, elles ne mesurent pas une adoption.
• Un échantillon de 400 documents donne des ordres de grandeur, jamais des taux : les pourcentages de ce rapport se lisent comme des repères de discussion.

Ce que je décris ici vient de 11 entretiens, de 3 observations de poste en ADV, de 2 exports de l'ERP sur 12 mois et de 400 documents tirés au hasard. C'est peu pour tout savoir, c'est assez pour voir où le travail se perd. Je décris le fonctionnement réel, pas celui des procédures.

Le chemin d'une commande

Une commande arrive par e-mail. Quelqu'un ouvre le message, puis la pièce jointe : un PDF, un tableur, parfois quelques lignes écrites dans le corps du message. Il lit, il retape les références une par une dans l'ERP, il vérifie le prix, il renvoie une confirmation au client. Ce trajet occupe une part importante des journées des 14 personnes de l'ADV.

Sur environ 4 800 commandes par mois, 61 % arrivent par e-mail, 27 % par le portail web et 12 % par téléphone. Cette répartition décide de la suite : les 27 % du portail arrivent déjà structurés et ne se retapent pas, les 12 % du téléphone ne relèvent pas d'un modèle de langage. Le sujet tient donc entier dans les 61 %, et nulle part ailleurs.

La documentation technique

Le distributeur conserve 34 000 fiches PDF fournisseurs. D'un fournisseur à l'autre, rien ne se ressemble : la structure, le vocabulaire, les unités. Environ 40 % de ces fiches sont des scans, c'est-à-dire des images de page, sans texte à l'intérieur.

La conséquence est concrète. Une recherche par mot clé ne voit pas ces 40 %. Un vendeur qui cherche un diamètre ou une norme dans une fiche scannée ne trouve rien, alors que l'information est bien là, visible à l'écran. Il ouvre alors les fiches une par une. C'est le point que les entretiens ramènent le plus souvent.

L'état des données

Deux faits pèsent plus que les autres. L'historique de l'ERP porte un trou de 7 mois en 2022, au moment de la migration : les mouvements de cette période n'ont pas été repris. Ce trou interdit une chose précise, la prévision statistique sur les ventes : un calcul de saisonnalité a besoin d'années complètes pour comparer un mois à lui-même, et 2022 n'est plus une année complète.

Le PIM, le référentiel qui décrit les produits, est partiel et alimenté à la main. Il interdit autre chose : servir de source de vérité. Aucun assistant ne peut affirmer un prix, un stock ou une caractéristique en s'appuyant dessus, faute de savoir si la fiche a été mise à jour. J'ai détaillé ailleurs ce qui rend un jeu de données exploitable : vos données sont-elles prêtes pour l'IA ?.

Le POC de 2025

Un chatbot client a été commandé à une agence en 2025, puis arrêté au bout de 4 mois. Je ne reproche rien à cette agence : l'erreur est banale, et elle est structurelle. Trois causes se cumulent, et aucune ne tient à la qualité du travail fourni.

• Aucune source de vérité n'était exposée sur le stock et les prix : le chatbot répondait sans rien pouvoir vérifier.
• Aucun jeu d'évaluation n'existait, donc personne ne pouvait dire s'il répondait juste, ni constater un progrès d'une version à l'autre.
• Aucune procédure d'escalade vers un humain n'était prévue, donc un client bloqué restait bloqué.

Ce POC n'a pas échoué à cause du modèle. Il a échoué parce qu'on lui a demandé de répondre sur des données qu'on ne lui avait pas données, sans aucun moyen de savoir s'il se trompait.

Ces trois manques se réparent, et ils se réparent ailleurs que dans le chatbot. C'est la raison pour laquelle je propose plus loin de commencer par autre chose.

L'ordre qui suit n'est pas un classement de mérite, c'est un ordre d'exécution. C1 fait plus de bruit dans l'entreprise : la saisie des commandes occupe l'ADV tous les jours, et c'est le sujet cité en premier dans les entretiens. C2 passe pourtant devant, pour une raison simple. C'est le seul des cinq cas dont on peut vérifier la qualité avant de le mettre entre les mains de quelqu'un, et sur un terrain où une erreur ne part pas chez un client. Commencer par lui, c'est apprendre à mesurer sur un périmètre sans conséquence, avant d'appliquer la même discipline à un chantier qui touche des commandes réelles.

C2 : recherche dans la documentation technique

La douleur est nommée par 9 des 11 entretiens, sans que la question soit posée. Un technicien cherche une cote, un couple de serrage, une équivalence entre deux références. Il ouvre trois fiches, il appelle un collègue, il finit par appeler le fournisseur. Personne ne sait dire combien de temps ça prend. Tout le monde sait dire que ça arrive plusieurs fois par jour.

L'assistant fait une chose et une seule : il retrouve les passages utiles dans les 34 000 fiches fournisseurs, et il répond en citant la fiche et la page. Il ne rédige pas d'argumentaire commercial, il ne devine pas un prix, il ne remplace pas le fournisseur. Quand il ne trouve pas, il le dit. C'est le schéma décrit dans l'assistant documentaire.

Trois raisons en font le premier chantier, et le verdict est oui, à lancer en premier. Le périmètre est borné : un corpus, une question, une réponse. La réponse est vérifiable parce qu'elle est sourcée : celui qui lit ouvre la fiche citée et tranche en dix secondes. Et le jeu d'évaluation, c'est-à-dire la liste des questions dont on connaît la bonne réponse, est constructible dès maintenant. Le support a déjà reçu ces questions. Elles sont dans les tickets et dans les boîtes mail, il suffit de les rassembler.

Ce qui le ferait échouer est connu d'avance. Environ 40 % des fiches sont des scans, donc des images sans texte exploitable. Si l'étape de lecture d'image est bâclée, l'assistant répondra à côté sur cette part du corpus, sans jamais signaler qu'il ne sait pas. Deuxième risque, un périmètre qui s'élargit en cours de route vers les prix, le stock et les conditions commerciales, trois sujets dont la source de vérité est ailleurs. Un point reste à vérifier avant de lancer : ce que les contrats fournisseurs autorisent en matière d'indexation interne.

C1 : saisie des commandes reçues par e-mail

Le verdict est oui, mais pas comme prévu. La demande initiale était une IA qui lit toutes les commandes arrivant par e-mail. L'export ERP dit autre chose : 62 % des lignes de commande viennent de 23 clients réguliers. Ces 23 clients peuvent envoyer un fichier structuré, c'est-à-dire un format que l'ERP sait lire seul. Reste 38 % des lignes, soit environ 900 documents par mois, dans des formats qu'aucune intégration ne couvrira : scans, tableurs bricolés, commandes tapées dans le corps du message. C'est là, et seulement là, que l'IA a un rôle.

Sur la part intégrable, une intégration de fichiers classique bat l'IA sur les trois critères qui comptent. Elle coûte moins cher à poser et à faire tourner. Elle ne se trompe jamais, parce qu'elle ne fait aucune inférence : soit le fichier est conforme, soit il est rejeté. Et elle ne consomme rien à l'usage, pas un token. Mettre un modèle de langage là où un format de fichier suffit, c'est payer une lecture à chaque document pour un travail qu'une correspondance entre champs règle une fois pour toutes.

La règle de mesure se pose avant le premier essai, pas après. On ne mesure pas le taux de réussite du modèle : ce chiffre ne veut rien dire pour l'ADV, qui ne compte pas des champs mais des commandes. On mesure la part des commandes intégrées sans reprise humaine, sur un échantillon relu ligne par ligne. C'est ce seul chiffre qui décide de continuer, d'ajuster ou d'arrêter. Le détail de la chaîne de lecture des documents est traité dans ce guide.

L'ordre est donc : intégration des 23 clients d'abord, extraction par IA ensuite, sur la traîne seule. Inverser les deux revient à faire lire par une machine des documents qui n'auraient jamais dû être des documents.

Une partie du travail d'un projet IA n'est pas de l'IA, et c'est souvent la partie qui produit le gain.

Trois pistes sur cinq ne partent pas maintenant. Deux sont reportées, une est écartée dans sa forme actuelle. Aucune ne l'est parce que le sujet serait sans intérêt, mais parce qu'une condition manque, et que cette condition est nommable.

C3 : Aide à la réponse aux appels d'offres

Verdict : plus tard, et ce n'est pas un refus. Répondre à un appel d'offres, c'est produire un document où chaque affirmation technique engage le distributeur. Un modèle de langage rédige très bien un paragraphe plausible. Sans base de recherche fiable derrière lui, il produit de la rédaction non sourcée, c'est-à-dire exactement le contraire de ce qu'un appel d'offres exige. Le risque n'est pas de perdre du temps, il est d'annoncer une caractéristique produit fausse et de s'y engager.

Ce qui le débloque est précis : que C2 tourne en production, avec des réponses sourcées et un jeu d'évaluation tenu à jour. Le jour où un rédacteur demande une caractéristique et reçoit la fiche fournisseur qui la porte, l'aide à la rédaction devient une couche mince posée sur une base saine. Avant ce jour, C3 n'est pas un chantier, c'est un pari.

C4 : Chatbot client sur le site

Verdict : non, pas maintenant. Non de calendrier, pas de principe. Le POC de 2025 s'est arrêté au bout de quatre mois pour trois raisons, et ces trois raisons n'ont pas bougé. Aucune source de vérité n'est exposée sur le stock et les prix. Aucun jeu d'évaluation n'existe, donc personne ne peut dire si l'outil répondait juste. Aucune procédure ne passe la main à un humain quand la machine sort de son périmètre. Relancer sans traiter ces trois points, c'est refaire l'échec avec un modèle plus récent.

Les trois conditions de réouverture se vérifient, elles ne se déclarent pas.

• Le stock et les prix sont lisibles par une machine, en temps réel, par une interface fournie par l'éditeur de l'ERP, et cette interface renvoie la même valeur que l'écran d'un commercial.
• Un jeu d'évaluation d'au moins deux cents questions clients réelles existe, avec la bonne réponse écrite à côté, et le taux de réponses justes est mesuré avant toute mise en ligne.
• Une règle d'escalade est écrite et testée : au bout de deux échecs, ou sur toute question de prix négocié, la conversation part vers l'ADV avec son historique.

S'ajoute la transparence : le règlement européen sur l'IA impose que l'utilisateur sache qu'il parle à une machine. Des cinq cas, ce chatbot public est le seul concerné. Une phrase à l'écran suffit, ce n'est pas un projet. Le cadre est repris dans l'IA Act expliqué aux entreprises.

C5 : Prévision des ruptures de stock

Verdict : ce n'est pas de l'IA générative. Prévoir une rupture, c'est lire l'historique des sorties, les délais fournisseurs et les saisonnalités, puis appliquer de la statistique. Un modèle de langage n'apporte rien ici, et il ajoute une source d'erreur là où le sujet demande de la régularité. Le vrai obstacle est ailleurs : l'historique de l'ERP a un trou de sept mois en 2022, à la migration. Une prévision calée sur une année incomplète se trompe avec assurance.

À la place : traiter ce trou, poser une méthode de calcul simple sur les références qui pèsent, et mesurer l'écart entre prévision et réel pendant un trimestre avant d'automatiser quoi que ce soit. C'est moins vendeur qu'un projet d'IA. C'est plus utile, et ce travail de données sert ensuite tous les autres cas, y compris ceux qu'on lance. La trame est dans vos données sont-elles prêtes pour l'IA.

Un cas écarté avec une condition écrite vaut mieux qu'un cas lancé sans savoir ce qui le ferait échouer.

Ce rapport ne convertit aucun gain en euros. Je ne connais pas votre coût horaire chargé, ni en ADV, ni au support. Vous le connaissez, et votre direction financière aussi. Un montant inventé dans un rapport d'audit décrédibilise tout ce qui l'entoure, y compris les parties qui tiennent. Je donne donc des heures par an, avec les termes du calcul posés à côté du résultat. La multiplication vous revient : elle prend dix secondes et elle donne un chiffre que vous pouvez défendre.

Deux chantiers portent un gain chiffrable dès maintenant : C2 sur la recherche documentaire, C1 sur la traîne des commandes reçues par e-mail.

Ces heures ne se transforment pas en postes supprimés, et je ne vous vendrai pas l'inverse. 630 heures par an réparties sur quatre agences et 14 personnes en ADV, cela fait quelques heures par semaine et par site. Ce qu'elles deviennent est plus utile : des commandes saisies le jour même plutôt que le lendemain matin, un client rappelé avant midi, et du travail de recopie que personne n'a jamais aimé faire, qui disparaît. Si votre objectif est de réduire l'effectif, dites-le maintenant, parce que le projet se pilote alors autrement et que je ne le présenterai pas aux équipes sous un autre nom.

Une heure gagnée devient un délai de réponse avant de devenir une ligne de budget.

Le coût de fonctionnement se calcule à partir de volumes, pas d'un forfait. C2 envoie environ 13,2 millions de tokens en entrée et 0,88 million en sortie par mois, le token étant l'unité de texte facturée par le modèle. C1 envoie environ 4,86 millions en entrée et 0,54 million en sortie. La formule est stable : coût = (tokens d'entrée en millions) x P_entrée + (tokens de sortie en millions) x P_sortie. P_entrée et P_sortie sont les prix publics du million de tokens du modèle retenu, au jour de la décision. Je ne les écris pas ici : ils bougent plusieurs fois par an, et un tarif recopié dans un rapport est faux avant d'être lu. Relevez le tarif du jour chez le fournisseur, posez-le dans la formule, et ajoutez l'hébergement et la supervision, qui ne sont pas des tokens. Le détail chantier par chantier, première indexation des fiches comprise, est en annexe A4, et les leviers qui font baisser la facture sont détaillés ici.

La charge de mise en oeuvre suit la même règle : elle est exprimée en jours dans le plan, jamais en euros. Je ne publie pas de grille tarifaire, et la page tarifs dit pourquoi : un prix affiché à l'aveugle serait faux pour votre cas. Le chiffre, vous l'avez au premier échange, avant tout engagement.

Quatre risques peuvent arrêter un de ces chantiers après son démarrage : la réglementation, les contrats fournisseurs, l'adoption et la dépendance à un prestataire. Les trois derniers pèsent ici plus lourd que le premier.

Ce que la réglementation demande ici

Le règlement européen sur l'IA, appelé « IA Act », impose une obligation de transparence : un utilisateur doit savoir qu'il parle à une machine. Cette obligation vise le cas C4, l'assistant ouvert aux clients sur votre site. Si vous le relancez un jour, il doit annoncer qu'il est une machine, et le passage vers un humain doit rester visible.

Les deux chantiers que je recommande de lancer ne sont pas dans ce périmètre. La recherche documentaire interne, C2, et l'extraction des commandes, C1, relèvent du risque minimal : ce règlement ne leur impose pas d'obligation particulière. Le point de vigilance est ailleurs. Les commandes contiennent des données personnelles, le nom et les coordonnées d'un acheteur par exemple, et le RGPD s'y applique comme il s'applique déjà à votre ERP. Ce n'est pas un sujet neuf, c'est le même sujet étendu à un traitement de plus. Pour le cadre général, voir l'IA Act expliqué aux entreprises.

Les catalogues fournisseurs

Les 34 000 fiches techniques viennent de vos fournisseurs. Les indexer pour que vos équipes les interrogent en interne n'est pas la même chose que les rediffuser à vos clients. La première lecture est défendable, la seconde ne l'est pas sans accord. Je ne tranche pas la question à votre place : elle se lit contrat par contrat, et vos 11 fournisseurs principaux n'ont pas les mêmes conditions d'usage. La réponse appartient à votre direction juridique, ou à votre conseil externe. Posez la question avant le prototype, pas après.

L'adoption

C'est le risque le plus sous-estimé de la liste. Un assistant que plus personne n'ouvre au bout de trois semaines a coûté sa mise en oeuvre et n'a rien rendu. Le POC arrêté en 2025 appartient à cette catégorie, et le passage du POC à la production se joue en grande partie là. Ce qu'on met en face n'a rien de spectaculaire, et se décide avant le premier jour de code.

• L'assistant s'ouvre dans l'outil déjà utilisé au quotidien, pas dans un onglet de plus à retenir.
• Trois personnes de l'ADV et deux du support essaient le prototype et disent ce qui ne va pas, avant toute ouverture large.
• Chaque réponse affiche ses sources, parce qu'une réponse invérifiable finit par ne plus être lue.
• Le nombre d'utilisateurs actifs par semaine est suivi dès le premier jour, comme la qualité des réponses.
• Une condition d'arrêt est écrite d'avance : si l'usage ne décolle pas en deux mois, on arrête et on dit pourquoi.

La dépendance

Formats ouverts, données exportables à tout moment, et le rapport comme le code produits pendant la mission vous appartiennent.

Sur ce dossier, le risque réglementaire est le mieux documenté et le moins probable. Le risque d'abandon est exactement l'inverse.

Cette feuille de route engage deux choses : un ordre entre les chantiers, et une condition de démarrage pour chacun. Elle n'engage pas un résultat. Personne ne peut promettre aujourd'hui que l'assistant documentaire tiendra le seuil visé, parce que le jeu d'évaluation qui permettrait de le vérifier n'existe pas encore. Ce qu'on peut poser, en revanche, c'est l'ordre dans lequel on lève les incertitudes, de la moins chère à la plus chère.

L'ordre suit une règle simple : on ne finance pas une étape tant que la précédente n'a pas produit sa preuve. Les charges sont exprimées en jours de mise en oeuvre. Elles ne comprennent ni le temps de vos équipes, ni l'hébergement, ni la consommation du modèle, qui se calcule à part.

Les chantiers des trois premiers mois se mènent en parallèle, mais ils ne reposent pas sur les mêmes personnes. L'intégration des fichiers des 23 clients est un sujet d'ERP, pas un sujet d'IA : elle revient à l'éditeur. Elle couvre à elle seule 62 % des lignes de commande, sans qu'aucun modèle intervienne. Si elle n'avance pas, le prototype d'extraction perd une partie de sa raison d'être, puisque l'IA se retrouverait à traiter un volume qui n'a pas à lui revenir.

Les critères d'arrêt

Un chantier s'arrête mieux tôt que tard. Voici les moments où on regarde, et ce qui doit faire arrêter plutôt que prolonger.

• À la fin des 4 jours de cadrage, si les questions déjà posées au support ne suffisent pas à construire un jeu d'évaluation que les métiers acceptent, on n'engage pas le prototype.
• À la fin du prototype de C2, si l'assistant reste sous le seuil fixé au cadrage, la mise en production, 20 jours et plus, n'est pas engagée.
• À la revue de fin de prototype, si les personnes du support ne l'ouvrent plus sans qu'on le leur rappelle, le besoin n'était pas là où on le croyait.
• En production, si le taux de réponses reprises à la main remonte deux mois de suite, on gèle les évolutions et on revient au jeu d'évaluation avant d'ajouter quoi que ce soit.
• Avant le prototype de C1, si l'éditeur de l'ERP n'a donné ni devis ni date pour les fichiers structurés, on ne démarre pas la partie IA.
• À chaque revue mensuelle, si le coût recalculé avec les tarifs du jour dépasse l'enveloppe posée au cadrage, on change de modèle ou on arrête, on ne laisse pas glisser.

Un chantier sans condition d'arrêt écrite n'a pas de condition de démarrage sérieuse.

Le découpage en cadrage, prototype, puis mise en production n'est pas propre à ce cas : c'est la manière dont je travaille, décrite dans ma méthode. Chaque étape se termine par une décision, et cette décision peut être de ne pas continuer.