Osez l'IA : que vérifier avant de payer un diagnostic ?

Avant de payer un diagnostic IA, faites inscrire au devis le problème à examiner, les accès autorisés, les livrables vérifiables et la personne qui décidera de la suite. À la restitution, demandez des pièces que votre équipe peut reprendre et des critères de test prêts à exécuter avant d'autoriser un prototype, une première version limitée du système destinée à l'essai.

Le plan Osez l'IA remet cette décision à l'agenda. Mais, pour un dirigeant, la question utile commence sur son bureau : que recevra-t-il exactement en échange du conseil acheté ? Une présentation peut éclairer un choix ; elle ne remplace pas les documents nécessaires pour construire un premier système et pouvoir l'arrêter.

Les décisions à garder sous la main

• Choisissez un travail précis à examiner, avec un début, une sortie attendue et un responsable métier.
• Ouvrez les accès progressivement, sur un extrait préparé pour l'étude ; chaque accès supplémentaire doit répondre à une question écrite.
• Demandez des livrables modifiables : inventaire des données, cas prioritaire, critères de test, budget expliqué et dossier de reprise.
• Séparez l'acceptation du diagnostic, le lancement du prototype et l'autorisation d'utiliser le système au quotidien.
• Préparez aussi une conclusion d'arrêt : elle peut être la bonne issue d'un diagnostic correctement réalisé.

Apport Origin : la grille de réception et le dossier fictif ci-dessous transforment ces principes en pièces à demander, vérifications à rejouer et décisions explicites. C'est une méthode proposée pour cet article, sans résultat client ni performance Origin revendiqués. Elle complète notre description des composants nécessaires à un agent en production en traitant l'étape précédente : ce que l'entreprise doit recevoir avant de financer sa construction.

Que disent réellement Bercy et l'Insee ?

Le communiqué Bercy du 3 septembre 2026 présente un bilan du plan Osez l'IA et annonce une nouvelle étape d'accompagnement. Anne Le Hénanff, ministre déléguée chargée de l'Intelligence artificielle et du Numérique, y formule cette orientation :

« Notre cap pour l'année qui vient est clair : passer de la sensibilisation à l'action […] »

Anne Le Hénanff, communiqué Bercy, 3 septembre 2026.

L'Insee Première n° 2120, publié le 21 juillet 2026, porte sur les usages en 2025 : 15 % des entreprises de 10 à 49 salariés du champ étudié déclarent utiliser au moins une technologie d'IA, contre 9 % en 2024. Le champ couvre les entreprises en France de dix salariés ou plus des secteurs principalement marchands, hors agriculture, finance et assurance. Ce n'est donc ni une mesure des toutes petites entreprises, ni un taux d'usage mesuré en septembre 2026.

Ces publications décrivent deux objets différents : une action publique et une enquête d'usage. Les rapprocher ne suffit pas à mesurer l'effet causal du plan. Pour votre entreprise, elles ne prouvent pas davantage qu'un outil sera utile sur le travail retenu. Cette utilité reste à vérifier localement.

Quel diagnostic achetez-vous exactement ?

Dans sa présentation du renforcement du plan Osez l'IA, Bpifrance décrit le Diagnostic Data IA comme l'intervention d'un expert pour examiner la situation technique et opérationnelle, identifier des usages concrets et les classer selon leur valeur pour l'entreprise. Le texte distingue ce dispositif d'un accompagnement plus long par les Accélérateurs IA. Identifier un projet et livrer un système exploitable restent deux engagements différents.

Quand une proposition commerciale emploie le mot « diagnostic », demandez le nom exact de la prestation et son périmètre. Un échange de découverte, une étude technique et un prototype peuvent tous être présentés avec ce vocabulaire, sans fournir les mêmes pièces. Si le prestataire évoque un dispositif public, faites confirmer par l'opérateur les conditions applicables à votre dossier. Cet article ne garantit ni financement, ni tarif, ni éligibilité, et ne présente pas l'offre Origin comme un Diagnostic Data IA labellisé par Bpifrance.

La méthode de réception proposée ici est une exigence d'achat à discuter avant signature. Elle ne prétend pas reproduire le cahier des charges officiel du dispositif. Si une vérification ou un livrable dépasse le diagnostic proposé, demandez une ligne séparée et décidez si elle mérite d'être commandée. C'est particulièrement important pour les essais logiciels : préparer leur protocole n'est pas forcément les exécuter.

Vous pouvez attendre d'un diagnostic qu'il précise les inconnues et le travail nécessaire pour les lever. Vous ne pouvez pas exiger honnêtement qu'une étude sans accès aux données prouve la qualité d'un futur traitement. La bonne restitution dira alors ce qui manque, qui peut le fournir et quelle décision reste suspendue. Elle ne remplacera pas la preuve manquante par une estimation présentée comme certaine.

Avant le devis, ramenez le besoin à une tâche observable

Préparez une page à partir du travail tel qu'il se déroule aujourd'hui. Nommez la personne qui reçoit la demande, les documents qu'elle consulte, la sortie qu'elle prépare et celui qui la valide. Ajoutez un dossier ordinaire et un dossier qui pose problème. Ce point de départ permet au prestataire de poser des questions concrètes sans aspirer toute votre documentation.

Une demande comme « mettre de l'IA dans le service maintenance » est trop large pour réceptionner quoi que ce soit. Une formulation plus exploitable serait : préparer un dossier d'intervention à partir d'une demande et de notices autorisées, en indiquant les informations manquantes. La programmation du rendez-vous et la transmission au client restent à part. Le livrable devient visible : un dossier que le responsable maintenance peut accepter ou corriger.

Écrivez également ce qui ne sera pas étudié. Si le diagnostic porte sur la préparation documentaire, il ne doit pas se transformer silencieusement en changement de logiciel métier, en refonte du planning ou en sélection automatique de techniciens. Ces sujets pourront revenir ; ils demandent d'autres données, d'autres interlocuteurs et une autre autorisation.

Demandez enfin au prestataire d'examiner une solution sans IA. Dans l'exemple, un formulaire mieux structuré et une recherche documentaire organisée pourraient suffire. La comparaison n'a pas besoin d'être spectaculaire : que manque-t-il à cette solution simple, et pourquoi l'IA serait-elle nécessaire pour le résoudre ? Si la réponse tient seulement au caractère séduisant d'une démonstration, le diagnostic n'a pas encore tranché la question.

Lecture du schéma : le devis fixe une question ; le diagnostic fournit un dossier ; une décision distincte ouvre ou arrête le prototype. Méthode Origin, 8 septembre 2026.

Quels accès donner au prestataire ?

Commencez avec une description du processus et des exemples préparés pour l'étude. Privilégiez des données fictives quand elles permettent d'expliquer le besoin. Si elles masquent justement la difficulté à examiner, préparez un extrait réel limité, validé par les personnes responsables des données. Enlever un nom ne rend pas automatiquement un document anonyme : son contenu peut encore permettre de reconnaître quelqu'un.

L'accès doit avoir une finalité écrite. Pour vérifier la présence d'une référence d'équipement, le consultant a besoin du champ correspondant et de sa qualité, pas des coordonnées bancaires du client. Pour comprendre comment un dossier est validé, une observation accompagnée peut être suffisante. Demandez quelle conclusion deviendrait impossible sans l'accès demandé, puis choisissez le moyen le moins exposant qui permette cette conclusion.

Inscrivez pour chaque source le propriétaire, les champs autorisés, le lieu de consultation, les personnes admises et la date de fin. Ajoutez la possibilité ou non de télécharger une copie et de la transmettre à un service d'IA. Une autorisation de lire dans votre outil ne répond pas à cette seconde question. Faites préciser les services tiers envisagés avant qu'un fichier y soit déposé.

La règle de travail recommandée pour l'étude est un compte nominatif temporaire, limité au périmètre accepté. N'envoyez pas les identifiants d'un salarié dans un document partagé. Si le prestataire demande des droits d'administration pour observer un processus, faites détailler l'opération exacte et cherchez d'abord une observation accompagnée ou un export limité. Les permissions nécessaires à un futur système devront ensuite faire l'objet de leurs propres essais.

Notre article sur les accès d'un agent à une base clients détaille ces protections dans l'architecture. Ici, la pièce à recevoir est plus simple : une liste des accès réellement ouverts, des copies créées et des destinations utilisées. Elle doit permettre à votre administrateur de fermer la mission sans devoir reconstituer ce qui s'est passé.

Ne confondez pas cette liste avec une validation juridique. Si les documents contiennent des données personnelles, des secrets commerciaux ou des informations contractuellement protégées, faites examiner le traitement envisagé par vos responsables compétents. Tant que l'usage n'est pas autorisé, le diagnostic peut continuer sur la description et les exemples fictifs ; il doit noter la limite qui en résulte.

Équivalent textuel : décrire d'abord, ouvrir ensuite un extrait autorisé, puis fermer les accès à la fin. Toute copie ou nouvelle destination exige une décision spécifique. Méthode Origin, 8 septembre 2026.

Quelles pièces doivent sortir du diagnostic ?

Demandez ces pièces au devis, puis ouvrez-les pendant la restitution. Une case « livré » doit renvoyer vers un fichier ou un constat précis. Un tableau de maturité peut aider à orienter la discussion, mais il ne remplit pas à lui seul les cases suivantes.

Pour la fiche du travail, exigez un exemple rempli. « Automatiser les documents » ne dit pas quels champs sont obligatoires ni qui relit. La fiche doit montrer une sortie acceptable et expliquer comment traiter une information absente ou contradictoire. Elle fournit au futur constructeur une définition du résultat, sans lui imposer prématurément un outil.

Pour l'inventaire, demandez aussi les défauts constatés : notices obsolètes, fichiers sans propriétaire, droits incertains, formats impossibles à lire. Un inventaire utile peut conclure que la donnée n'est pas prête. Dans ce cas, la première commande suivante porte sur sa préparation, si l'entreprise en accepte l'effort, et non sur un prototype dont les entrées restent inconnues.

Pour la comparaison, faites écrire la raison du classement des usages. Le prestataire peut recommander de commencer par le dossier documentaire parce que sa sortie reste contrôlable avant toute action. Il doit aussi expliquer pourquoi une autre idée est reportée. Le planning automatique pourrait dépendre de disponibilités non fiables : ce défaut vaut plus pour la décision qu'une note générale d'attractivité.

Le budget doit distinguer ce qui est chiffré, ce qui est estimé et ce qui ne peut pas encore l'être. Demandez le coût de préparation des données, de construction, des services utilisés, de contrôle humain, de maintenance et de sortie du dispositif. Pour une dépense variable, écrivez la quantité supposée et ce qui se passe si elle augmente. Une ligne « consommation selon usage » sans mécanisme de suivi ne permet pas d'autoriser la suite en connaissance de cause.

Quels critères rejouer avant de lancer le prototype ?

À la réception du diagnostic, vous ne testez pas encore les performances d'un système inexistant. Vous vérifiez que le futur essai peut être exécuté et jugé. Prenez un exemple du dossier, demandez à un responsable métier d'écrire le résultat attendu, puis à un autre de l'évaluer avec la grille proposée. S'ils ne savent pas appliquer le même critère, celui-ci n'est pas assez précis pour départager une solution.

Construisez le jeu d'essai autour des situations qui changent la décision. Il faut un cas ordinaire, mais aussi un document manquant, une référence ambiguë et une demande extérieure au périmètre. Ce ne sont pas des quotas universels. Le nombre d'exemples dépend de la diversité du travail et de la gravité d'une erreur. Un petit ensemble peut valider la compréhension du protocole sans démontrer une fiabilité statistique.

Formulez les critères comme des observations. « Le dossier est de bonne qualité » laisse trop de place à l'impression. « Chaque référence d'équipement renvoie à la pièce qui la contient ; une référence absente est signalée comme manquante » donne au relecteur quelque chose à vérifier. Définissez également les erreurs qui interdisent de poursuivre, même si le reste du dossier est satisfaisant.

Préparez la mesure du travail complet. Le temps de génération seul ne représente pas le temps jusqu'à un dossier accepté : il faut compter la recherche, les corrections et la validation. Le diagnostic peut proposer comment relever ces durées, sans annoncer de gain avant l'essai. Demandez qui les observera et comment seront conservés les résultats, y compris les tentatives abandonnées.

Le protocole doit enfin préciser ce qui déclenche une nouvelle évaluation. Si le périmètre documentaire change, les résultats obtenus sur les anciennes notices ne valident pas les nouvelles. Si le prototype obtient un droit d'écriture qui n'existait pas pendant l'essai, il faut examiner cette action séparément. Le dossier reçu doit rendre cette limite visible dès maintenant.

Lecture du schéma : retrouver une entrée, appliquer un critère, consigner le constat, puis décider. À ce stade, on valide le protocole de test ; la performance du prototype reste à mesurer. Méthode Origin, 8 septembre 2026.

Cas appliqué fictif : préparer une intervention de maintenance

Imaginons Atelier Rivage, une entreprise fictive de maintenance. Tous les noms, volumes et choix de ce cas sont des hypothèses pédagogiques, pas des données client ni des résultats observés. Son responsable, Malik, souhaite que les demandes d'intervention arrivent avec les documents utiles, sans que l'IA choisisse une réparation ou promette un délai.

Le périmètre retenu est la préparation d'un dossier de lecture : référence de l'équipement, description reçue, notice autorisée correspondante et informations manquantes. Sont exclus le diagnostic de panne, les consignes de sécurité, l'affectation d'un technicien et tout envoi au client. Cette limite rend le projet plus facile à examiner : le système proposé prépare une matière que Malik contrôle, il ne décide pas de l'intervention.

Dans ce scénario fictif, l'entreprise prépare vingt demandes inventées : dix ordinaires, trois sans référence d'équipement, trois dont la notice manque, trois avec deux références contradictoires et une demandant d'affecter automatiquement un technicien. Cette répartition sert seulement à vérifier que la grille est utilisable. Elle ne représente ni la fréquence réelle des anomalies ni un échantillon permettant de prouver une fiabilité en production.

La fiche d'accès remplie autorise la consultation d'un dossier d'étude contenant ces demandes et des notices sélectionnées par Malik. Le compte du prestataire lit ce dossier uniquement. Aucun accès à la messagerie, au planning ou au logiciel client n'est demandé. La copie vers un service tiers reste interdite tant que le service et l'usage ne sont pas examinés. À la fin de l'étude, la responsable informatique, Nora, ferme le compte et fait consigner le devenir des copies éventuelles.

La fiche de résultat remplie décrit ce que doit contenir chaque dossier : l'identifiant de la demande, la référence retrouvée avec sa pièce d'origine, le document associé et un statut « complet », « à compléter » ou « hors périmètre ». Si les références divergent, la sortie doit afficher le désaccord. Aucun remplacement silencieux par la référence jugée la plus probable n'est admis dans ce scénario.

La comparaison remplie retient d'abord un formulaire qui impose la référence d'équipement. Cette solution traite une partie du problème sans IA. L'étude conserve ensuite une question à tester : une assistance à la recherche dans les notices apporte-t-elle une valeur au-delà de ce formulaire ? Le prototype éventuel devra répondre à cette question précise, sans réintroduire le planning automatique.

Le protocole rempli demande à Malik et à sa collègue Sarah de noter les dossiers fictifs séparément. Ils doivent retrouver la même pièce justificative et le même statut attendu. Une notice absente doit être signalée ; la demande d'affectation doit être identifiée comme hors périmètre, sans action sur le planning. Un désaccord devient une correction du protocole. Aucun résultat de modèle n'est encore inscrit : les vingt exemples sont préparés, pas exécutés par une IA. Le registre comporte donc une colonne « attendu » remplie et une colonne « observé » encore vide.

Le budget rempli, toujours fictif, réserve une enveloppe maximale de 3 000 euros hors taxes au prochain essai, uniquement si un devis séparé est accepté. Ce montant est une contrainte choisie pour l'exemple, sans rapport avec le tarif du Diagnostic Data IA. La ventilation reste à fournir : préparation documentaire, construction et accompagnement de l'essai. En l'absence de cette ventilation, la dirigeante n'autorise aucune dépense de prototype.

La réception remplie accepte la fiche métier, les exclusions et le jeu de dossiers fictifs. Elle émet une réserve sur l'accès aux notices réelles : leur responsable doit confirmer les droits d'utilisation. Elle demande aussi le devis ventilé. La décision est donc « diagnostic reçu avec réserves ; prototype non autorisé ». Le prestataire sait ce qu'il doit compléter ; l'entreprise sait ce qui manque pour décider.

Ce scénario montre une issue intermédiaire utile. L'étude a clarifié le travail et produit des pièces réutilisables, mais elle n'a démontré ni économie, ni qualité de traitement, ni conformité du futur système. Si les notices restent indisponibles, la dirigeante peut choisir le formulaire seul et clore le projet IA. Le diagnostic garde sa valeur puisqu'il a rendu cette décision explicable.

Qui peut arrêter, valider et engager la suite ?

Nommez les personnes, pas seulement les services. Le responsable métier valide le sens du dossier et les critères d'acceptation. Le responsable des accès autorise l'environnement de travail et peut le fermer. La direction autorise la dépense et le passage à l'étape suivante. Le prestataire prépare les preuves et propose une conclusion ; il ne s'accorde pas lui-même les droits ou le budget supplémentaires.

Dans une petite structure, une même personne peut porter plusieurs responsabilités. Écrivez tout de même les décisions séparément. Accepter une facture d'étude ne signifie pas autoriser l'accès à la base clients. Approuver une sortie documentaire ne signifie pas autoriser son envoi automatique. Cette distinction protège aussi le prestataire contre une commande dont les limites changeraient après coup.

Prévoyez la procédure d'arrêt avant le démarrage : qui peut couper l'accès, où signaler l'incident et comment poursuivre manuellement le travail. Pour le diagnostic, l'arrêt peut simplement consister à suspendre un partage de fichiers et à reprendre les entretiens. Pour le prototype, il faudra vérifier la fermeture effective des connexions et le traitement des opérations déjà engagées.

Une réserve doit avoir un propriétaire et une condition de clôture. « Sécurité à revoir » ne permet aucune reprise. « Nora confirme les droits sur les notices sélectionnées et inscrit la liste autorisée dans le dossier » permet de savoir quand réexaminer la décision. Si personne ne peut fermer la réserve, ne la transformez pas en acceptation implicite parce que la réunion se termine.

Équivalent textuel : le métier valide le résultat attendu, le responsable des accès contrôle les données, la direction engage la suite. Une réserve non levée maintient l'arrêt sur le périmètre concerné. Méthode Origin, 8 septembre 2026.

Que récupérer si vous changez de prestataire ?

Faites inscrire la remise de fichiers modifiables et les droits d'utilisation convenus. Demandez le rapport, les fiches métier, l'inventaire autorisé, les exemples, leurs critères et les calculs de budget avec leurs hypothèses. Si un essai logiciel fait partie de la commande, ajoutez ses instructions de lancement, ses réglages et ses résultats. Distinguez vos données, les travaux livrés et les composants que le prestataire conserve sous licence.

Faites ensuite un essai de reprise documentaire. Une personne qui n'a pas assisté aux entretiens doit pouvoir retrouver l'objectif, ouvrir un exemple autorisé et expliquer la décision avec le dossier seul. Si elle dépend d'une explication orale du consultant pour identifier les fichiers valides, demandez un index et des consignes de lecture. Ce test porte sur la transmission de l'étude, pas sur la capacité à maintenir un logiciel qui n'existe pas encore.

Enfin, clôturez les accès avec une liste datée : comptes fermés, partages retirés, copies rendues ou supprimées selon l'accord, éléments conservés et raison de conservation. Demandez une confirmation écrite du prestataire ; vérifiez ce que vos propres outils permettent de constater. Un dossier bien transmis laisse l'entreprise libre de poursuivre, de consulter un autre constructeur ou de s'arrêter.

Pour préparer ce cadrage, vous pouvez réserver un échange de cadrage de 30 minutes avec Origin Labs. Apportez un exemple de travail et les livrables que vous souhaitez recevoir. Cet échange sert à examiner le besoin ; il ne comprend pas l'étude payante et les livrables décrits ici. Il ne constitue ni une attribution d'aide publique ni une validation du futur déploiement.

FAQ

Un diagnostic IA doit-il contenir un prototype ?

Seulement si la commande le prévoit. Le diagnostic peut fournir un périmètre, des données examinées, un protocole et une recommandation sans livrer de logiciel. Faites préciser quels essais sont inclus et lesquels nécessitent une décision ultérieure. Une démonstration ajoutée à la restitution ne prouve pas que le futur système est prêt.

Peut-on commencer sans donner accès à ses données clients ?

Oui, pour décrire le travail et préparer les critères avec des exemples fictifs. La faisabilité sur les données réelles restera alors non vérifiée. Le prestataire doit identifier ce qui dépend d'un accès supplémentaire et justifier celui-ci avant ouverture. L'entreprise peut refuser cet accès et accepter une conclusion plus limitée.

Que faire si le rapport recommande seulement des outils ?

Demandez le lien entre chaque recommandation, le problème retenu, les données nécessaires et la vérification prévue. Si ces pièces étaient commandées et manquent, inscrivez une réserve de réception. Si elles n'étaient pas incluses, clarifiez le complément avant de l'acheter. Une liste de logiciels ne suffit pas à définir les responsabilités d'un prototype.

Un financement public garantit-il le résultat du diagnostic ?

Ne déduisez pas la qualité ou la réussite future d'une prise en charge. Vérifiez séparément les conditions du dispositif auprès de son opérateur et les engagements écrits du prestataire. La décision de construire repose sur le dossier reçu et les inconnues restantes, pas sur l'existence d'une aide.

Faut-il continuer si le diagnostic conclut à un arrêt ?

Pas nécessairement. Une conclusion motivée peut montrer qu'une solution simple suffit, que les données manquent ou que le contrôle coûterait trop d'effort. Récupérez les pièces produites et consignez ce qui justifierait un réexamen. Vous pourrez reprendre la décision lorsque cette condition aura changé.

Comment cet article a été préparé

Recherche et rédaction assistées par IA, avec consultation des sources institutionnelles le 8 septembre 2026. La grille est une proposition méthodologique Origin ; Atelier Rivage est un scénario fictif entièrement construit pour l'illustrer. Aucun essai logiciel ni mesure de performance n'a été réalisé pour ce guide.

Sources

• Ministère de l'Économie, communiqué n° 990 du 3 septembre 2026 sur Osez l'IA, bilan et citation d'Anne Le Hénanff.
• Clément Lefebvre, Insee, Les technologies de l'information et de la communication dans les entreprises en 2025, Insee Première n° 2120, paru le 21 juillet 2026, figure 1 et champ de l'enquête.
• Bpifrance, Renforcement du plan national Osez l'IA, périmètre des dispositifs, consulté le 8 septembre 2026.