Ce qu'un Partenaire d'Implémentation IA Doit Livrer : Les Cinq Documents à Exiger

Ce qu’un partenaire de mise en œuvre de l’IA doit vous remettre : cinq documents, pas une présentation

Vous ne pouvez pas inspecter la liste de clients d’un prestataire, car les bons ne nomment pas leurs clients, et ceux qui le font vous montrent des logos, pas du travail. Vous ne pouvez pas inspecter une équipe d’ingénieurs. Vous pouvez inspecter un document. Cet article liste les cinq documents qu’un partenaire de mise en œuvre de l’IA doit remettre à chaque mission, dans l’ordre où ils sont produits, en précisant qui, dans votre organisation, lit chacun d’eux et ce qu’il lui permet de décider. Si un partenaire ne sait pas les nommer, ou produit à la place une présentation d’avancement, vous avez appris quelque chose d’utile avant de signer.

Cette liste n’a rien d’arbitraire. C’est l’ensemble des livrables qui répond aux cinq questions que se pose réellement un acheteur : le partenaire sait-il comment notre travail fonctionne réellement, quelle part relève réellement de l’IA, comment saurons-nous que le système est toujours juste, pouvons-nous défendre une décision qu’il a prise, et cela implique-t-il de remplacer notre logiciel. Une présentation d’avancement ne répond à aucune d’elles. Les cinq documents répondent chacun à l’une d’elles.

1. Le Registre des exceptions : le partenaire sait-il comment le travail fonctionne réellement ?

Le Registre des exceptions est un relevé écrit de chaque écart réel par rapport au processus documenté : ce qui le déclenche, sa fréquence et la personne qui l’absorbe aujourd’hui. C’est le premier document, parce que tout le reste en dépend, et c’est celui qui ne peut pas être produit à partir d’un atelier ou d’un questionnaire. Il naît du temps passé à côté de la personne qui fait tourner le workflow, assez longtemps pour voir les quarante formats d’e-mail, le client qui téléphone, la facture fournisseur qui renvoie à un bon de commande inexistant, et la validation qui part chez un autre manager le vendredi.

Qui le lit : le directeur des opérations. Ce qu’il lui permet de décider : si le processus mérite d’être automatisé, et à quelles exceptions l’automatisation devra résister. Une exception que personne n’a consignée devient une étape que le modèle est censé traiter en silence, et c’est ainsi qu’un pilote qui a réussi la démo meurt au deuxième mois. Nous avons décrit le problème de fond dans pourquoi le processus documenté n’est jamais le processus réel.

Le test pour un partenaire : demandez-lui combien de temps il passe avec celles et ceux qui font le travail avant de rédiger un périmètre. Une journée, c’est trop peu. Un trimestre, c’est de la facturation, pas de la découverte. Cinq jours sur un workflow, c’est l’ordre de grandeur qui permet de rédiger le registre sans que la facture devienne l’objectif.

2. La Carte des frontières IA : quelle part relève réellement de l’IA ?

La Carte des frontières reprend le workflow étape par étape et qualifie chaque étape : code déterministe, jugement d’un modèle ou décision qui reste entre les mains d’une personne. Le chiffre clé qu’elle produit est le ratio de déterminisme : la part des étapes qui relèvent du logiciel classique. Il est généralement plus élevé que ne le supposait la présentation du fournisseur. Dans le traitement des commandes d’un industriel européen cartographié par SUPALABS, trois étapes sur onze nécessitaient réellement un modèle ; les huit autres relevaient de l’extraction de données, de la recherche dans des référentiels, de la validation et du routage (données de mission SUPALABS, 2024–2026).

Qui la lit : le DSI, et le responsable du budget. Ce qu’elle leur permet de décider : ce que coûtera l’exploitation du système, sa rapidité, et ce qui pourra être présenté à un auditeur comme une règle plutôt que défendu comme un échantillon. Chaque étape tenue à l’écart du modèle coûte moins cher, va plus vite et est reproductible. Un partenaire incapable de produire cette carte vend soit une plateforme tarifée comme si chaque étape était une étape difficile, soit n’a pas regardé d’assez près pour le savoir.

Le test pour un partenaire : demandez-lui quelle part du système proposé est déterministe. Un partenaire qui répond « tout est de l’IA » décrit sa démo. Un partenaire qui répond par un chiffre et une liste décrit votre processus. Vous pouvez consulter les nôtres avant même de nous parler : un Registre des exceptions et une Carte des frontières IA caviardés, issus d’une mission réelle.

3. La Suite d’évaluation : comment saurons-nous que le système est toujours juste ?

La Suite d’évaluation est un jeu de données de référence (golden dataset) constitué à partir de vos propres cas passés, les commandes que votre équipe a traitées correctement, les factures rapprochées, les brouillons qu’un professionnel senior aurait acceptés, évalués étape par étape, avec des taux de réussite par étape et un rapport mensuel de précision mesuré sur ce jeu après le lancement. Elle doit faire l’objet d’une ligne distincte du devis, jamais intégrée au développement, car une évaluation noyée dans un forfait est la première chose que l’on supprime quand le développement prend du retard.

Qui la lit : le responsable de la transformation, et le dossier du conseil. Ce qu’elle leur permet de décider : si le système est toujours juste six mois après le départ du partenaire, et si une tâche a mérité davantage d’autorité. La suite est aussi ce qui rend les niveaux d’autorité concrets : une tâche ne passe du brouillon à l’action autonome que lorsque le taux de réussite que vous avez fixé est atteint sur des cas réels, et elle redescend lorsque le rapport mensuel signale une régression. Sans la suite, « l’humain dans la boucle » est un slogan ; avec elle, c’est un seuil.

Si cela compte davantage chaque année, c’est parce que la confiance dans les résultats des modèles baisse à mesure que leur usage progresse. L’enquête Stack Overflow 2025 auprès des développeurs montre que 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA, alors que 46 % se méfient activement de leur précision et que seuls 33 % lui font confiance. Ce sont les personnes qui construisent ces systèmes. Un directeur des opérations à qui l’on demande de faire confiance à l’un d’eux en production est en droit d’exiger un chiffre, pas une assurance.

Le test pour un partenaire : demandez à voir la ligne consacrée à l’évaluation sur le devis. Si elle n’y figure pas, demandez pourquoi. Si elle est intégrée à un forfait, demandez ce qu’elle devient quand le développement prend du retard.

4. Le Journal des décisions : pouvons-nous défendre une décision prise par le système ?

Le Journal des décisions consigne chaque action automatisée, ses données d’entrée, son niveau de confiance et la personne qui l’a validée, dans une interface qu’un responsable conformité, un contrôleur de gestion ou l’équipe de due diligence d’un acquéreur peut ouvrir sans solliciter un ingénieur. Le construire, c’est le minimum attendu. Toute la différence tient au fait qu’on vous le montre, sous une forme lisible par un non-ingénieur, avant que vous ne signiez.

Qui le lit : la conformité, la finance, et toute personne qui devra un jour expliquer une décision à un régulateur, à un auditeur ou à un acquéreur. Ce qu’il leur permet de décider : si chacune des décisions prises par le système peut être reconstituée et défendue. Pour une entreprise qui rend des comptes à l’administration fiscale, à l’inspection du travail ou à un régulateur financier, c’est la différence entre un processus automatisé et un processus inexplicable.

Le test pour un partenaire : demandez à voir un Journal des décisions issu d’une mission passée, anonymisé. Un partenaire qui ne peut pas en montrer un soit n’en construit pas, soit ne pense pas que vous le demanderez.

5. L’Engagement ERP : cela implique-t-il de remplacer notre logiciel ?

Le cinquième document est le plus court et le plus souvent absent : un engagement écrit, pris au départ, selon lequel le partenaire construit sur les systèmes que vous utilisez déjà et ne proposera pas de les remplacer. Pas une préférence. Une clause. Un programme de refonte de plateforme est le plus grand risque de carrière qu’un responsable des opérations ou de l’informatique puisse prendre, et ce n’est presque jamais ce que le problème exige ; le workflow est lent à cause des exceptions et des passages de relais, pas à cause de la base de données qui se trouve en dessous.

Qui le lit : le DSI, et la personne qui porterait la migration. Ce qu’il leur permet de décider : que cette mission n’est pas une refonte de plateforme déguisée. L’engagement a un second volet qu’il vaut la peine d’exiger dans la même clause : quand la mission se termine, le système reste. Il tourne dans vos comptes, sur vos systèmes, documenté pour votre équipe dès la première semaine, et arrêter le service n’arrête pas le workflow.

Le test pour un partenaire : demandez-lui s’il inscrira « aucun remplacement, aucune migration » dans le périmètre. Un partenaire qui tergiverse garde la migration en réserve.

Pourquoi l’ordre compte

Les partenaires qui produisent certains de ces documents les produisent souvent dans le mauvais ordre, et c’est dans l’ordre que réside la valeur. La Carte des frontières ne peut pas être tracée tant que les exceptions ne sont pas consignées par écrit, car une exception non consignée devient une étape que le modèle est censé traiter en silence. La Suite d’évaluation ne peut pas être construite tant que la Carte des frontières n’indique pas quelles étapes comportent un jugement à évaluer ; évaluer une recherche dans un référentiel n’a aucun intérêt. Le Journal des décisions n’a de sens qu’une fois que la suite a défini ce qu’est une décision correcte. Et l’engagement doit venir avant tout le reste, car tout le reste est conçu autour de systèmes que vous conservez. Sautez une étape et la suivante devient une supposition. C’est la séquence décrite en détail sur la page de la méthode SUPALABS, et c’est pourquoi les cinq mêmes documents sortent de chaque mission, quel que soit le secteur, ce qui les rend également comparables si vous achetez pour plusieurs unités opérationnelles ou, comme nous l’expliquons aux fonds sur la page consacrée au private equity, pour plusieurs participations.

Ce que ces documents remplacent

Les cinq documents remplacent trois choses que l’on propose habituellement aux acheteurs à la place. Ils remplacent le mur de logos, car un document sur votre processus est plus instructif qu’une liste d’entreprises dont vous ne pouvez pas voir les processus. Ils remplacent le témoignage client, car un rapport mensuel de précision est un témoignage que le système rédige sur lui-même. Et ils remplacent la présentation méthodologique, car une présentation est la même pour tous les clients, alors que ces documents ne le sont pas. Si un partenaire vous propose les trois premiers et ne peut pas produire les cinq, l’écart est la réponse.

Sources & références