Projet IA en entreprise : faut-il cadrer en interne, organiser un atelier ou mener un audit ?

01Choisir le type de cadrage selon le blocage à lever

Un projet IA ne réclame pas automatiquement un audit, un atelier ou une longue étude. Le bon mode de cadrage dépend de la question qui reste ouverte au moment de décider. Tant que cette question n’est pas nommée, l’entreprise risque de choisir la prestation la plus visible ou la plus rassurante, sans obtenir l’information dont elle a réellement besoin.

Le premier contrôle consiste à oublier momentanément l’outil envisagé. Quel travail doit être amélioré ? Qui rencontre le problème ? Quelles contraintes rendent la situation difficile ? Comment saura-t-on si le projet mérite d’être poursuivi ? Des guides publics de conception de services recommandent précisément de comprendre le problème, les personnes concernées et les contraintes avant de retenir une solution. Ils indiquent aussi qu’il peut être raisonnable de ne pas poursuivre.^[11][14] Ce raisonnement n’impose aucune méthode particulière à une PME ; il rappelle seulement qu’un projet ne gagne rien à commencer par une technologie déjà choisie.

La grille proposée ici distingue quatre situations. Il s’agit d’une analyse de farweb.fr, et non d’une norme institutionnelle.

Quatre situations, quatre suites possibles

Cette distinction évite deux confusions fréquentes. Un atelier n’est pas un audit collectif : il ne crée pas les données qui manquent. Un audit n’est pas non plus un prototype : il établit des faits pour permettre la décision, sans engager implicitement la construction de la solution. L’entreprise gagne à formuler la question par écrit avant de discuter du mode de cadrage, du calendrier ou du prestataire.

La question à formuler avant toute proposition

« Quelle information ou quel arbitrage manque encore pour décider s’il faut poursuivre ce projet IA, le reformuler ou l’abandonner ? »

Une réponse précise oriente le cadrage. Une réponse vague signale qu’il faut encore préciser le problème.

02Cinq conditions pour cadrer le projet en interne

Le cadrage interne est le choix le plus économe lorsque l’entreprise possède déjà l’essentiel : un problème observable, l’accès aux personnes concernées, des informations exploitables et un décideur disponible. Il ne signifie pas « discuter entre soi jusqu’à trouver une idée ». Il consiste à préparer une décision avec des faits, des limites et une responsabilité clairement attribuée.

Le décideur n’a pas besoin de réaliser toutes les analyses. Il doit en revanche pouvoir préciser le résultat recherché, autoriser l’accès aux informations, arbitrer les priorités et accepter qu’un projet soit différé ou écarté. Les cadres de gouvernance du National Institute of Standards and Technology et du gouvernement britannique insistent sur l’explicitation des responsabilités, du niveau de décision, des preuves attendues et des cas dans lesquels la décision doit être portée à un niveau supérieur.^[1][2][5] Ils ne prescrivent pas un organigramme unique ; ils soutiennent l’idée qu’une décision sans décideur clairement identifié reste fragile.

Un cadrage interne peut tenir dans un document court si ce document répond à des questions concrètes :

La qualité du cadrage dépend moins de son volume que de la possibilité de contester l’hypothèse de départ. Si « installer un assistant IA » est déjà considéré comme une conclusion, l’équipe cherchera surtout à justifier l’outil. Si le problème est formulé comme « les conseillers passent du temps à retrouver les conditions applicables à chaque dossier », plusieurs réponses restent possibles : mieux structurer la documentation, corriger les droits d’accès, simplifier la procédure ou tester une assistance automatisée.

Le cadrage interne cesse d’être suffisant lorsque l’une de ses conditions disparaît. L’équipe peut posséder les données sans être en mesure d’arbitrer entre rapidité, qualité et risque. Elle peut partager une priorité sans savoir si les documents sont réellement utilisables. Elle peut enfin disposer d’une idée séduisante mais d’aucun responsable prêt à assumer les décisions. Ces limites ne condamnent pas le projet ; elles indiquent seulement qu’un autre mode de cadrage doit traiter le blocage précis.

Le cadrage interne est crédible si ces cinq conditions sont réunies

Si l’une de ces conditions n’est pas remplie, il faut préciser ce qui manque avant d’ajouter des réunions ou des analyses.

03Quand un atelier permet de trancher les désaccords

Un atelier devient utile lorsque les faits principaux sont disponibles, mais qu’ils ne conduisent pas tous les responsables à la même conclusion. Le métier peut privilégier la rapidité, la direction des systèmes d’information peut privilégier la maintenabilité, le juridique peut privilégier la maîtrise des données et la direction peut vouloir démontrer un résultat. Ces priorités ne sont pas des obstacles irrationnels à faire disparaître. Elles doivent être rendues comparables afin qu’un décideur puisse arbitrer.

L’atelier ne sert donc ni à sensibiliser largement, ni à recueillir des idées sans fin, ni à obtenir artificiellement un consensus. Sa préparation doit isoler les décisions à prendre, les faits déjà établis et les limites non négociables. Les participants sont choisis pour leur rôle dans la décision ou dans le travail concerné, pas pour remplir une salle. Le cadre du National Institute of Standards and Technology et le guide britannique sur l’IA recommandent d’associer les responsables métier, techniques, juridiques, de la sécurité et des données, ainsi que les utilisateurs, lorsque le contexte l’exige.^[1][5]

La facilitation organise la confrontation des points de vue sans en déterminer l’issue. Dans une recommandation générale, un rapport de l’OCDE sur la délibération indique que le facilitateur soutient les échanges sans avoir d’intérêt propre dans leur issue ; cette référence vient d’un autre contexte et ne prouve pas l’efficacité d’un atelier en entreprise, mais elle rappelle une distinction utile : le facilitateur aide à rendre le choix possible, il ne décide pas à la place du commanditaire.^[7]

Une étude de laboratoire publiée en 2010 a par ailleurs observé une association entre performance collective, sensibilité sociale et répartition plus équilibrée de la parole.^[6] Elle ne démontre ni qu’un atelier améliore la qualité de la décision, ni qu’une séance IA produira le même effet. Elle invite simplement à éviter un dispositif dans lequel une fonction, un statut ou une expertise monopolise l’échange.

Un atelier qui prépare réellement une décision

Un atelier mal préparé ne fait que déplacer le flou. Si la discussion révèle que personne ne connaît la qualité des données, les droits d’accès ou le coût d’une erreur, la réponse rigoureuse n’est pas de voter. L’audit doit alors porter précisément sur cette information manquante. Inversement, si toutes les informations sont disponibles mais que personne n’accepte de trancher, une analyse supplémentaire ne réparera pas l’absence d’autorité.

04Quand un audit ciblé devient nécessaire

Un audit ciblé est justifié lorsque la décision dépend d’un fait que l’entreprise ne peut pas établir de manière suffisamment fiable. La question peut porter sur la qualité d’un corpus documentaire, l’origine des données, les droits d’accès, la fréquence des exceptions, le degré d’exposition aux erreurs ou les contraintes d’intégration. Plus la question est précise, plus l’audit peut être court, utile et contrôlable.

Le mot « audit » ne doit pas transformer chaque incertitude en mission générale. Il faut se demander quel constat changerait la décision. « Auditer la maturité IA de l’entreprise » définit un périmètre presque illimité. « Vérifier si les procédures utilisées par le service sont à jour, qu’un responsable est identifié pour chacune, qu’elles sont accessibles et que leurs droits d’accès sont cohérents » définit une vérification précise, fondée sur des faits observables. Le livrable attendu peut alors distinguer les faits établis, les limites de vérification et les conséquences pour le projet.

Certaines questions relèvent d’obligations juridiques précises. L’article 35 du RGPD prévoit qu’une analyse d’impact relative à la protection des données est requise lorsqu’un traitement de données personnelles est susceptible d’engendrer un risque élevé.^[8] Cela ne rend pas cette analyse obligatoire pour tout projet IA et n’en fait pas un audit global de la solution. De même, le règlement européen sur l’IA prévoit, pour certains systèmes à haut risque, un système de gestion des risques^[3] et des mesures de contrôle humain.^[3] Ces exigences ne doivent pas être étendues indistinctement à chaque usage.

Les référentiels NIST et OCDE, ainsi que les pages publiques des normes ISO/IEC 42001 et 23894, proposent des repères volontaires pour relier responsabilités, contexte, mesure et gestion continue des risques.^{[1][4][9][10]} Ils peuvent aider à construire une grille de vérification adaptée. Ils ne constituent ni une obligation générale de certification, ni la preuve qu’un audit externe est nécessaire, ni un modèle à appliquer sans tenir compte de l’organisation.

Le périmètre minimal d’un audit utile

Un bon audit peut conclure qu’une information reste impossible à établir. Cette conclusion n’est pas un échec si elle empêche une décision présentée à tort comme sûre. Elle peut conduire à réduire l’ambition, modifier le périmètre, organiser une expérimentation très limitée ou abandonner l’usage envisagé.

05Le consultant éclaire la décision sans la prendre

Un consultant peut structurer le problème, conduire les entretiens, faciliter un atelier ou établir des constats. Il ne doit pas endosser implicitement une décision qui revient à l’entreprise et engage ses équipes, ses données, son budget et son exposition au risque. La recommandation éclaire le choix ; le décideur désigné conserve l’autorité.

Cette séparation protège aussi le prestataire. Sans décideur disponible, chaque conclusion peut être réinterprétée lors de la réunion suivante. Sans critères explicites, une recommandation devient une préférence parmi d’autres. Sans mention écrite des limites de l’analyse, un document de cadrage peut être relu plus tard comme une promesse de résultat. Les cadres de responsabilité du National Institute of Standards and Technology et de l’OCDE relient justement les décisions, leur documentation et la gestion des risques aux rôles attribués et au contexte de l’organisation.^[1][4]

Exemple hypothétique : un assistant pour le service après-vente

Une PME industrielle envisage un outil d’IA générative pour préparer les réponses de son service après-vente. La responsable métier dispose de dossiers clos et peut décrire les demandes récurrentes. Le projet pourrait donc sembler prêt pour un cadrage interne.

Le commerce souhaite des réponses plus rapides, tandis que le juridique refuse qu’un brouillon cite une condition contractuelle sans validation. Les faits de départ sont partagés, mais les priorités conduisent à des choix différents. Un atelier au périmètre clairement défini permet de comparer les usages acceptables, les validations requises et les cas à exclure.

La séance révèle ensuite que les droits d’accès aux pièces jointes ne sont pas documentés et que certains dossiers mêlent plusieurs contrats. La discussion ne permet pas de lever ces deux incertitudes. Un audit ciblé doit vérifier les droits, la qualité du classement et la fréquence des exceptions avant toute expérimentation.

Si l’audit lève ces incertitudes et si l’entreprise retient un usage limité, la suite change de nature. Elle peut tester une hypothèse avec un prototype de périmètre réduit, puis décider d’intégrer la solution en tenant compte de la sécurité, de l’accessibilité, de la mesure des résultats et de l’exploitation. Les guides du service numérique du gouvernement britannique distinguent ainsi la compréhension du problème, l’expérimentation sur les hypothèses les plus risquées et la réalisation du service.^[11][12][13] Cette distinction clarifie le passage du cadrage à la réalisation ; elle ne dicte pas le contenu d’un éventuel contrat de réalisation.

L’exemple montre que ces modes d’intervention ne se succèdent pas nécessairement. Si les droits d’accès avaient déjà été établis, l’atelier aurait pu conduire directement à une décision. Si les responsables s’étaient accordés dès le départ, le cadrage interne aurait peut-être suffi. Si le risque avait rendu l’usage disproportionné, l’arrêt aurait été une issue rationnelle.

06La fiche de décision qui clôt le cadrage

La fin du cadrage ne se résume pas à un compte rendu de réunion. Le cadrage doit aboutir à un document qui permet à une personne absente de comprendre la décision retenue, ses fondements et ses limites. Le document peut rester court, à condition de ne pas masquer les inconnues ni confondre recommandation et engagement de réalisation.

La fiche de décision à conserver

Une expérimentation ne doit commencer que si elle répond à une hypothèse explicite. Les guides publics britanniques recommandent de tester les hypothèses les plus risquées avec des prototypes limités à ce qui est nécessaire pour les vérifier, puis de réserver la réalisation du service au moment où une solution a été choisie et où les exigences d’intégration, de sécurité, d’accessibilité, de mesure et d’exploitation peuvent être prises en charge.^[12][13] Ce principe reste applicable sans reprendre l’intitulé ni la durée de ces phases.

Le passage à la réalisation doit faire l’objet d’un contrat distinct. Le cadrage répond à la question « que faut-il décider et pourquoi ? ». La réalisation répond à « comment concevoir, tester et intégrer la solution retenue ? ». Mélanger les deux incite à protéger la solution déjà vendue au lieu de vérifier qu’elle répond bien au problème.

La décision à consigner avant la réalisation

Consignez le problème retenu, le responsable de la décision, le mode de cadrage choisi, les inconnues résiduelles et les conditions de poursuite. Cette fiche indique s’il faut travailler en interne, organiser un atelier, demander un audit ciblé ou engager une mission de réalisation.