Cadrer un projet IA en entreprise : le guide

Dans beaucoup d'entreprises, un projet d'intelligence artificielle (IA) commence par une démonstration convaincante. Un outil résume une note d'analyse, classe des pièces comptables ou répond à des questions sur un contrat, et la direction se demande aussitôt pourquoi cela n'est pas déjà en service partout. Puis le projet ralentit. L'outil fonctionne, mais personne ne sait précisément quel problème il résout, sur quel périmètre, avec quelles données, ni qui doit décider de la suite. Le blocage est rarement technique au départ. Il vient d'un cadrage insuffisant, c'est-à-dire de la phase de travail qui précède le développement et qui répond à des questions simples en apparence : quelle tâche améliorer, pour qui, à partir de quelle base, avec quelles données, et à quelles conditions passer à l'étape suivante.

Ce guide s'adresse aux dirigeants, aux directeurs financiers, aux associés de fonds d'investissement et aux responsables de cabinets d'expertise comptable qui doivent décider d'un projet d'IA ou le piloter. Il suit le chemin réel d'un cadrage, de la première question jusqu'à la feuille de route. Il aborde successivement la formulation du besoin, la délimitation de ce qui est concerné, l'état de départ et la qualité des données, la priorisation des candidats, l'organisation des responsabilités, puis la distinction entre un essai limité et une mise en service réelle. Chaque notion technique est expliquée au moment où elle apparaît, et le glossaire en fin d'article reprend les définitions.

Cet article présente une méthode pour reformuler une idée de projet en situation de travail précise, conduire un diagnostic structuré autour de quatre dimensions (processus, données, décisions et compétences), construire une priorisation que vous pourrez défendre devant un comité, repérer les pièges les plus fréquents et écrire une feuille de route dont chaque étape se termine par une décision explicite. Les questions réglementaires et les règles d'usage des outils demandent un traitement à part. Ce guide en présente les principes, mais leur application concrète doit toujours être vérifiée avec un juriste.

Pourquoi un cadrage est indispensable#

Un projet IA ne se comporte pas comme un logiciel classique#

Un logiciel de gestion applique des règles connues : une même saisie produit le même résultat, et la validation consiste à vérifier que chaque fonction se comporte comme prévu. Un système d'IA fonctionne autrement. Les systèmes fondés sur des modèles de langage ou sur d'autres modèles statistiques produisent des réponses probabilistes, c'est-à-dire calculées à partir de régularités observées dans des données, avec une part d'incertitude. Un modèle de langage est, pour simplifier, un système entraîné à produire un texte plausible à partir d'une demande. Sa réponse peut être juste, incomplète ou fausse, et elle peut varier d'un essai à l'autre.

Cette différence a trois conséquences pour le cadrage. D'abord, la qualité ne se décrète pas : elle se mesure sur des cas réels, ce qui suppose de savoir à l'avance à quoi ressemble une bonne réponse. Ensuite, la qualité dépend fortement de l'information fournie au système, si bien qu'un projet IA est autant un projet sur l'information qu'un projet sur l'outil. Enfin, le système vit dans le temps : les documents changent, les pratiques évoluent, les données se dégradent. Il se gère donc comme une activité d'exploitation et non comme une livraison que l'on referme.

Ce que le cadrage doit produire#

Cadrer, c'est répondre par écrit à une série de questions avant d'engager des moyens importants. Un cadrage utile produit au minimum :

Une fiche de cas d'usage : elle décrit la situation de travail visée, le résultat attendu, les personnes concernées et la manière dont la réponse sera vérifiée. Elle sert de référence à toutes les discussions suivantes, et c'est elle qu'il faut relire lorsque le projet dérive.
Un périmètre écrit, avec ce qui est inclus, ce qui est exclu et ce qui est reporté.
Un diagnostic qui examine le processus, les données, les décisions et les compétences.
Une priorisation qui justifie pourquoi ce projet passe avant d'autres.
Une répartition des rôles et des instances de décision claires.
Une feuille de route phasée, dont chaque étape se termine par une décision.

La première question : quel problème métier veut-on résoudre ?#

Dans de nombreux projets qui échouent ont démarré par une technologie et non par un besoin. La question de départ doit donc être formulée dans les termes du métier : quelle tâche, quelle décision, quelle situation de travail pose aujourd'hui une difficulté identifiable ? La réponse prend la forme d'un cas d'usage, c'est-à-dire une situation de travail précise dans laquelle une aide algorithmique pourrait apporter une valeur identifiable à une personne ou à une équipe.

Un cas d'usage utile tient en une phrase : pour qui, dans quelle situation, à partir de quelle information, quelle aide est apportée, et qui valide le résultat. Par exemple : « Pour l'équipe de clôture, lors de la revue des rapprochements bancaires, classer les écarts selon leur origine probable, avec validation par le responsable de la comptabilité fournisseurs. » Cette phrase paraît modeste, mais elle permet de vérifier que le besoin existe, qui le porte et comment on saura qu'il est satisfait.

Un bon cas d'usage présente quatre qualités :

Il porte sur une tâche répétée ou une décision fréquente, car c'est la répétition qui permet d'observer un effet. Un événement exceptionnel ne fonde pas un usage durable.
Il est borné : on sait où il commence et où il s'arrête. « Aider la direction financière » est un domaine, pas un cas d'usage.
Il est mesurable au sens où il existe une méthode pour comparer la situation avant et après l'introduction de l'outil, même si les mesures ne sont pas encore prises.
Il a un responsable qui connaît le travail réel et accepte de valider les résultats.

Distinguer l'idée, le cas d'usage et le prototype#

Trois niveaux doivent être séparés. L'idée est une intention vague, comme « utiliser l'IA pour la paie ». Le cas d'usage est la fiche précise décrite plus haut. Le prototype est une réalisation technique qui montre qu'une partie du cas d'usage peut fonctionner. Beaucoup de projets se perdent en passant directement de l'idée au prototype. Le prototype répond alors à une question que personne n'a posée, et il est difficile de dire ce qu'il prouve.

Délimiter le périmètre#

Le périmètre est l'ensemble de ce qui est concerné par le projet : les étapes de processus touchées, les équipes impliquées, les données utilisées, les entités juridiques, les documents et les décisions que le système peut influencer. Un périmètre bien tracé dit explicitement ce qui est inclus, ce qui est exclu et ce qui est reporté. Un périmètre flou, en revanche, transforme chaque réunion en négociation : chacun ajoute son sujet, et le projet cesse d'être maîtrisable.

Il est utile de le définir selon quatre axes :

Le périmètre fonctionnel précise quelles étapes du processus sont concernées. Un outil qui aide à rédiger une synthèse n'intervient pas forcément sur la validation de cette synthèse, et cette différence doit apparaître noir sur blanc.
Le périmètre de données liste les sources autorisées : systèmes de gestion, dossiers partagés, messageries, bases documentaires. Il précise aussi celles qui sont exclues, par exemple pour des raisons de confidentialité.
Le périmètre de décision distingue ce que le système se contente de proposer de ce qu'il déclenche automatiquement. Dans une première phase, une proposition suivie d'une validation humaine est presque toujours le choix le plus prudent.
Le périmètre de risque identifie les conséquences d'une erreur et les personnes qui les subiraient. Il conditionne le niveau de contrôle à prévoir.

Une règle pratique : si le périmètre ne tient pas dans une synthèse courte, il contient probablement plusieurs projets. Il faut alors en isoler un, le plus petit qui reste utile, et inscrire les autres dans une liste d'idées à réexaminer.

Le diagnostic en quatre dimensions#

Un diagnostic de cadrage examine le contexte du cas d'usage selon quatre dimensions : le processus, les données, les décisions et les compétences. Ces dimensions ne sont pas indépendantes. Un processus mal documenté produit des données incohérentes, qui conduisent à des décisions difficiles à justifier, lesquelles supposent des compétences que l'équipe ne possède pas encore. Le diagnostic a pour rôle de rendre ces liens visibles avant que le projet ne les découvre à ses dépens.

Dimension	Question centrale	Éléments à documenter	Signal d'alerte
Processus	Comment le travail se fait-il réellement ?	Étapes, acteurs, exceptions, points de friction entre étapes	La procédure écrite diffère nettement de la pratique observée
Données	Où se trouve l'information nécessaire, et peut-on lui faire confiance ?	Sources, propriétaires, définitions, historique, droits d'accès	Plusieurs versions d'un même objet circulent
Décisions	Qui décide quoi, sur quels critères, avec quelles conséquences ?	Points de décision, critères implicites, niveau de validation	Les critères n'existent que dans la tête de quelques personnes
Compétences	Qui sait faire, contrôler et expliquer ?	Savoir-faire métier, maîtrise des outils, capacité d'évaluation	Un seul expert détient une connaissance clé

Le processus#

Le processus est l'enchaînement réel des tâches qui conduisent à un résultat. Il faut distinguer le processus prescrit, décrit par les procédures, et le processus réel, qui inclut les contournements, les raccourcis et les exceptions. C'est le second qui conditionne en grande partie la valeur d'un outil. Une aide insérée dans une étape que les équipes contournent risque fort de ne pas être utilisée. La méthode la plus fiable consiste à suivre quelques dossiers réels de bout en bout, puis à comparer le résultat avec la procédure écrite.

Les données#

Le diagnostic des données répond à trois questions : où se trouve l'information nécessaire à la tâche, qui en est responsable, et dans quel état elle est. On vérifie si un même terme recouvre la même réalité dans deux services, si les champs indispensables sont renseignés, à quelle fréquence l'information est mise à jour et qui peut y accéder. Ce diagnostic alimente l'évaluation de la dette de données, c'est-à-dire des écarts accumulés entre les données disponibles et celles dont le cas d'usage a besoin. Cette dette est traitée plus loin.

Les décisions#

Un projet IA modifie généralement une décision ou la prépare. Il faut donc décrire les décisions concernées : qui les prend, à partir de quelles informations, selon quels critères et avec quelles conséquences en cas d'erreur. Beaucoup de critères restent implicites. Les écrire est souvent le premier apport du diagnostic, même si le système n'est jamais mis en service.

Les compétences#

Le diagnostic des compétences ne se réduit pas à la question « qui connaît l'IA ? ». Il faut identifier qui maîtrise le métier avec assez de finesse pour juger une réponse, qui sait traiter les données, qui peut expliquer le fonctionnement de l'aide aux utilisateurs, et qui sera capable de surveiller la qualité dans le temps. L'absence de l'une de ces compétences n'interdit pas le projet, mais elle doit figurer dans le plan avec une réponse explicite : formation, recrutement, appui extérieur ou renoncement à certaines fonctions.

Le processus de référence et le point de départ mesuré#

Ces deux notions sont indissociables. Un projet ne peut démontrer une amélioration que par rapport à quelque chose. Ce quelque chose est le processus de référence, c'est-à-dire la manière actuelle, documentée et partagée, de réaliser la tâche, et le point de départ mesuré, c'est-à-dire l'état de cette tâche avant tout changement, décrit à l'aide d'indicateurs définis avec précision.

Le processus de référence#

Le processus de référence est la photographie du travail tel qu'il est aujourd'hui réalisé, du déclenchement jusqu'à la livraison, avec ses variantes et ses exceptions. Il doit être figé à une date donnée, pour que l'on sache à quoi comparer les résultats. Il doit aussi être écrit avec les personnes qui le pratiquent, et non seulement avec celles qui le pilotent. Lorsque le projet modifie une étape, le processus est mis à jour avec un historique, afin que les versions successives restent comparables entre elles.

Le point de départ mesuré#

Le point de départ répond à une question simple : avant le projet, où se situe la tâche sur les dimensions qui comptent ? Il se construit à partir d'indicateurs dont la formule est écrite à l'avance. Par exemple :

Temps moyen de traitement : somme des durées mesurées sur les dossiers de l'échantillon, divisée par le nombre de dossiers de cet échantillon.
Taux de retour : nombre de dossiers renvoyés pour correction, divisé par le nombre total de dossiers traités sur la période de référence.
Écart de qualité : différence entre le taux d'anomalies observé avant le projet et celui qui est observé ensuite, rapportée au taux initial.

Trois précautions s'imposent. L'échantillon doit être représentatif, c'est-à-dire couvrir les types de dossiers habituels et pas seulement les cas faciles. La période de référence doit être suffisamment longue pour absorber les variations normales d'activité, afin de ne pas confondre une période calme avec une amélioration. Enfin, ce qui n'est pas compté doit être écrit : une mesure sans périmètre de comptage produit des débats sans fin.

Sans point de départ mesuré, tout le reste devient une affaire d'impression. Les équipes disent que le travail est lourd, la direction pense qu'il est fluide, et personne ne peut trancher. Ce travail de mesure est un investissement de cadrage à part entière, et il est souvent sous-estimé.

La donnée de référence et la dette de données#

La donnée de référence#

Une donnée de référence est la version d'une information que l'organisation a décidé de considérer comme faisant autorité. Un fichier de tiers, un plan de comptes, une liste de codes d'activité ou un registre de contrats en sont des exemples typiques. Lorsqu'une même information existe en plusieurs exemplaires, dans un tableur, un logiciel de gestion et une boîte de messagerie, ces exemplaires finissent par diverger. Un système qui s'appuie sur la mauvaise copie peut produire une réponse cohérente avec une information fausse, ce qui est bien plus difficile à détecter qu'une erreur évidente.

Le cadrage doit donc identifier la donnée de référence de chaque objet traité par le cas d'usage, désigner son responsable et vérifier que les systèmes en aval la lisent bien à partir de la même source. On parle parfois de source de vérité pour désigner cette donnée qui fait autorité.

La dette de données#

La dette de données désigne l'ensemble des écarts accumulés entre l'état réel des données et ce qu'il faudrait pour que le cas d'usage fonctionne de façon fiable. L'image vient de la dette technique, bien connue des équipes informatiques : elle se constitue par des raccourcis successifs, elle pèse sur chaque nouveau projet qui la rencontre, et elle doit être remboursée de façon planifiée plutôt que subie.

On distingue généralement quatre familles de dette :

La dette de qualité regroupe les doublons, les valeurs manquantes, les fautes de saisie et les formats incohérents. Elle se détecte par des contrôles systématiques sur un échantillon.
La dette de définition apparaît lorsqu'un même terme désigne deux réalités selon les services, par exemple une « affaire » ou un « client actif ». Elle est souvent plus coûteuse que la précédente, car elle touche au sens et pas seulement à la forme.
La dette d'accès concerne les données nécessaires mais difficiles à obtenir, dispersées dans des fichiers personnels ou protégées par des droits mal documentés.
La dette de traçabilité est l'absence d'historique : on ne sait plus qui a modifié une information, à quelle date et sur quelle base. La traçabilité désigne au contraire la capacité à reconstituer ce chemin, ce qui est indispensable pour expliquer une décision assistée par un système.

Pour évaluer la dette, on compare pour chaque donnée de référence son état observé aux exigences du cas d'usage, puis on classe les écarts selon leur gravité. Une grille à trois niveaux (faible, moyenne, élevée) suffit généralement, à condition de justifier chaque niveau par une observation. La dette qui bloque le cas d'usage doit être traitée avant toute mise en service. Celle qui ne fait que compliquer le travail peut être inscrite dans un plan d'amélioration des données.

Prioriser avec une matrice valeur, faisabilité et risque#

Une organisation dispose rarement d'une seule idée. Il faut donc choisir, et le choix doit être défendable. La méthode la plus courante repose sur trois critères : la valeur, la faisabilité et le risque. La matrice est la grille de lecture qui croise ces critères pour classer les candidats. Elle ne produit pas une vérité : elle organise une discussion dont les hypothèses sont visibles.

Critère	Question posée	Éléments de preuve attendus	Erreur fréquente
Valeur	Quelle amélioration concrète le cas d'usage apporte-t-il à la tâche ou à la décision ?	Point de départ mesuré, fréquence de la tâche, importance de la décision, étendue des personnes concernées	Confondre le confort d'un utilisateur et la valeur pour l'organisation
Faisabilité	Peut-on le réaliser avec les données, les systèmes et les compétences disponibles ?	Diagnostic en quatre dimensions, qualité de la donnée de référence, accès aux systèmes, disponibilité des experts	Sous-estimer la dette de données
Risque	Que se passe-t-il si la réponse est fausse, incomplète ou mal comprise ?	Conséquences d'une erreur, sensibilité des données, exigences réglementaires, possibilité de contrôle humain	Traiter le risque comme une simple question de communication

Lire la matrice#

La matrice se lit en croisant la valeur et la faisabilité, le risque agissant comme un filtre qui conditionne le cadre de mise en œuvre. Le risque ne compense jamais la valeur : un cas d'usage très prometteur mais sensible ne doit pas être écarté, mais il doit entrer dans un cadre plus exigeant. Le tableau suivant propose une lecture type des profils les plus fréquents.

Profil	Lecture	Décision typique
Valeur élevée, faisabilité élevée, risque maîtrisé	Candidat prioritaire	Lancer une preuve de concept, c'est-à-dire un essai limité décrit plus loin
Valeur élevée, faisabilité faible	Enjeu réel bloqué par les données ou l'organisation	Traiter d'abord les prérequis, puis réévaluer
Valeur modeste, faisabilité élevée	Amélioration de confort sans enjeu majeur	Garder en réserve ou utiliser comme cas d'apprentissage
Risque élevé, quelle que soit la valeur	Usage sensible qui exige un encadrement renforcé	Décider après revue par le référent risque et le juriste
Valeur modeste, faisabilité faible	Peu d'intérêt pour l'instant	Abandonner ou reporter

Noter sans fausse précision#

Les niveaux doivent rester qualitatifs (faible, moyen, élevé) et être justifiés par écrit. Une note attribuée sans justification crée une fausse précision : elle donne l'impression d'une analyse objective alors qu'elle traduit une opinion. Il est préférable que chaque critère soit évalué par la personne la mieux placée, le responsable métier pour la valeur, le responsable données pour la faisabilité, le référent risque pour le risque, puis que les écarts soient confrontés en réunion. Les désaccords sont souvent la partie la plus instructive du processus.

Les rôles autour du projet#

Un projet IA mal réparti échoue souvent faute de responsable identifié, plutôt que par excès de complexité. Quatre rôles doivent être désignés explicitement. Dans une petite structure, une même personne peut en cumuler plusieurs, mais cela doit être une décision assumée et non un oubli.

Le sponsor est le dirigeant qui porte le projet devant l'organisation. Il arbitre les conflits de priorités, débloque les moyens et répond du projet devant la gouvernance. Son rôle n'est pas de piloter le détail, mais de s'assurer que le projet reste relié à un enjeu réel. Le piège classique est le sponsor distant, qui valide le lancement puis disparaît jusqu'à la demande de bilan.

Le responsable métier#

Le responsable métier connaît le travail réel. Il définit le cas d'usage, valide le processus de référence, juge de la qualité des réponses et décide de l'usage concret. Il accepte aussi de faire évoluer ses pratiques. Sans lui, le système est conçu pour un travail imaginé et non pour le travail réel.

Le responsable données#

Le responsable données veille à la qualité, à la définition et à l'accès aux données de référence. Il identifie la dette de données, propose un plan de traitement et contrôle les droits d'accès. Il n'est pas forcément informaticien : sa compétence est de savoir ce que signifie une donnée et qui peut la corriger. Son absence fait peser sur les équipes techniques des questions de sens qu'elles ne peuvent pas trancher seules.

Le référent risque#

Le référent risque évalue les conséquences d'une erreur, vérifie l'encadrement réglementaire, définit les contrôles humains et organise les revues. Il peut venir de la conformité, de l'audit interne, de la sécurité des systèmes d'information ou du juridique, selon la taille de l'organisation. Son rôle n'est pas de bloquer le projet, mais de rendre explicite le niveau de risque accepté et la personne qui l'accepte.

Le comité de pilotage#

Le comité de pilotage est l'instance de décision du projet. Il réunit le sponsor, le responsable métier, le responsable données et le référent risque, à intervalle régulier défini à l'avance. Son rôle n'est pas de suivre l'avancement des tâches, mais de prendre les décisions qui engagent le projet : passer à l'étape suivante, modifier le périmètre, arrêter.

Un comité efficace travaille à partir d'un support court : l'état des indicateurs par rapport au point de départ, les risques ouverts, les écarts constatés et les décisions demandées. Chaque décision est écrite, datée et attribuée. Trois types de décisions reviennent en pratique :

Poursuivre : les résultats répondent aux critères fixés, et le projet passe à l'étape suivante selon le plan validé.
Ajuster : l'objectif reste pertinent, mais le périmètre, les données ou le processus doivent être modifiés avant de continuer. L'ajustement doit être documenté, sinon il devient une dérive progressive.
Arrêter : les hypothèses ne tiennent pas, ou le coût de les vérifier est disproportionné par rapport à l'enjeu. Un arrêt bien documenté est un résultat utile : il peut libérer des moyens et limiter la reconduite d'un projet par simple inertie.

Le comité doit aussi savoir réagir entre les réunions lorsqu'un incident survient. Il est donc utile de prévoir une procédure d'urgence, avec un décideur identifié, capable de suspendre le système.

Évaluer la qualité avant de décider#

Un système d'IA ne se valide pas en le regardant fonctionner sur quelques exemples flatteurs. Il faut un jeu d'évaluation, c'est-à-dire un ensemble de cas réels, représentatifs de la tâche, pour lesquels la bonne réponse a été établie par des experts avant le test. Ce jeu doit contenir les cas courants, mais aussi les cas difficiles : informations incomplètes, documents ambigus, exceptions de procédure.

Les réponses sont ensuite évaluées selon une grille explicite. Chaque critère doit être défini avec précision : exactitude de l'information, complétude, respect des consignes, citation des sources internes, absence d'invention. Pour chaque critère, on sépare les réponses conformes des réponses non conformes, puis on calcule la proportion de réponses conformes, selon la formule suivante : nombre de réponses conformes, divisé par nombre total de réponses évaluées. Ce qui compte est moins la valeur obtenue que le fait qu'elle soit calculée de la même façon à chaque itération.

Deux précautions supplémentaires. D'abord, les erreurs ne se valent pas : une erreur qui conduit à une décision difficile à corriger pèse bien plus lourd qu'une formulation maladroite. La grille doit donc distinguer les erreurs bloquantes des erreurs tolérables. Ensuite, le jeu d'évaluation doit être conservé et enrichi, car il deviendra l'instrument de surveillance du système en exploitation. Un projet sans jeu d'évaluation n'a aucun moyen objectif de dire si la qualité s'améliore ou se dégrade.

Preuve de concept et passage en production#

La preuve de concept#

La preuve de concept (souvent abrégée en POC, de l'anglais « proof of concept ») est un essai circonscrit qui répond à une question précise de faisabilité. Elle porte sur un périmètre réduit, avec des données représentatives mais limitées, et elle est conçue pour apprendre avant de s'engager davantage. Les questions typiques sont les suivantes : la qualité atteint-elle le seuil fixé dans la grille d'évaluation ? Les données nécessaires sont-elles réellement accessibles ? Les utilisateurs acceptent-ils la forme de l'aide proposée ?

Une preuve de concept n'a pas vocation à être déployée telle quelle. Elle n'est généralement pas reliée aux systèmes de production, ne traite pas toutes les exigences de sécurité et ne supporte pas une utilisation généralisée. Son résultat attendu est une décision documentée : poursuivre, ajuster ou arrêter.

Le piège principal est ce que l'on appelle parfois l'effet démonstration. Une démonstration préparée avec soin, sur des exemples choisis, donne l'impression que le problème est résolu. La preuve de concept doit donc être évaluée avec le jeu d'évaluation, sur des cas qui n'ont pas été choisis pour leur facilité.

Le passage en production#

La mise en production consiste à faire entrer le système dans les processus réels, avec les exigences que cela implique : intégration aux outils existants, gestion des droits d'accès, journalisation des usages (enregistrement automatique de qui a fait quoi, avec quelle information), supervision humaine, surveillance de la qualité dans le temps, procédure de retour arrière, documentation et responsabilités d'exploitation.

La supervision humaine désigne le principe selon lequel une personne compétente contrôle les résultats et conserve la décision finale, en particulier lorsque les conséquences sont importantes. Le responsable d'exploitation est la personne qui assure le fonctionnement courant du système, répond aux incidents et déclenche les mises à jour.

Le tableau suivant résume les différences entre les deux étapes :

Critère	Preuve de concept	Mise en production
Objectif	Répondre à une question de faisabilité	Fournir un service stable dans un processus réel
Périmètre	Réduit, choisi pour apprendre	Défini, étendu progressivement et documenté
Données	Extraits représentatifs, parfois préparés à la main	Flux réguliers, droits d'accès, qualité surveillée
Qualité	Évaluée sur le jeu d'évaluation	Surveillée en continu, avec seuils d'alerte
Supervision	Équipe projet très présente	Procédure de contrôle humain formalisée
Sécurité et conformité	Vérifications minimales, données limitées	Exigences complètes, revues et journalisation
Responsable	Équipe projet	Responsable d'exploitation nommé
Sortie	Décision de poursuivre, d'ajuster ou d'arrêter	Mise en service, suivi et révisions périodiques

Les critères de passage#

Le passage de la preuve de concept à la production doit être conditionné par des critères écrits avant le test, et non négociés après coup. Il est recommandé de vérifier au minimum que la qualité mesurée atteint le seuil défini, y compris sur les cas difficiles ; que la dette de données bloquante a été traitée ; que le processus de référence est mis à jour pour intégrer le nouvel outil ; que les responsabilités d'exploitation et de réponse aux incidents sont attribuées ; que le plan de surveillance est prêt ; et que le comité de pilotage a validé la décision par écrit.

La feuille de route phasée#

Une feuille de route phasée découpe le projet en phases successives. Chaque phase a un objectif, des livrables, des critères d'entrée et de sortie, et se termine par une décision de passage. Le mot « phasée » insiste sur le fait qu'on n'avance pas d'un bloc : on avance par étapes, dont chacune peut conduire à ajuster ou à arrêter.

Une feuille de route ne doit pas être confondue avec un calendrier engagé. À ce stade du cadrage, les échéances précises restent des hypothèses, car elles dépendent des résultats des phases précédentes. Ce qui doit être engagé, c'est l'ordre des décisions et leurs critères.

Phase	Objectif	Livrables principaux	Décision attendue
Cadrage	Formuler le cas d'usage, délimiter le périmètre, établir le diagnostic	Fiche de cas d'usage, diagnostic, point de départ mesuré, priorisation	Retenir ou écarter le cas d'usage
Preuve de concept	Répondre aux questions de faisabilité sur un périmètre réduit	Jeu d'évaluation, résultats, liste des dettes de données bloquantes	Poursuivre, ajuster ou arrêter
Déploiement contrôlé	Mettre en service auprès d'un groupe limité d'utilisateurs	Procédures, formation, plan de surveillance, journalisation	Étendre, maintenir ou revenir en arrière
Exploitation et amélioration	Maintenir la qualité et étendre le périmètre lorsque les critères sont remplis	Tableaux de bord de qualité, revues périodiques, plan d'amélioration des données	Réviser le périmètre ou clore l'usage

Ce qu'une bonne feuille de route ne fait pas#

Une bonne feuille de route ne prévoit pas la généralisation à toutes les équipes dès le départ. Elle liste explicitement ce qui n'est pas prévu à ce stade : l'extension à d'autres processus, l'intégration à tous les systèmes, la couverture de tous les sites ou filiales, les nouveaux cas d'usage. Cette liste de renoncements aide à limiter l'expansion progressive qui le rend ingérable. Elle montre aussi que les travaux sur les données peuvent se dérouler en parallèle, à condition que leurs dépendances soient connues.

Une feuille de route sans décision n'est qu'un planning. Chaque phase doit donc nommer la personne qui décide, les critères utilisés et le document qui conserve la décision.

Les pièges classiques#

Trois pièges reviennent souvent dans les projets qui s'enlisent. Deux autres, plus discrets, méritent aussi d'être connus.

L'outil d'abord#

Le symptôme est facile à reconnaître : un outil est souscrit, ou une démonstration est organisée, avant que le cas d'usage soit défini. La cause tient souvent à une pression commerciale, à un effet de mode ou au désir de montrer une initiative. Une parade consiste à rédiger la fiche de cas d'usage, puis à comparer les solutions disponibles selon des critères précis : localisation des données, conditions contractuelles, sécurité, capacité d'intégration aux systèmes existants et réversibilité, c'est-à-dire la possibilité de changer de solution sans perdre ses données. L'outil n'est pas un ennemi, mais il ne peut arriver qu'après le besoin.

Le périmètre flou#

Le symptôme est une fiche de cas d'usage qui contient des expressions du type « et aussi », « éventuellement » ou « à terme ». La cause est le désir de tout traiter d'un coup, souvent au nom de l'efficacité. Une parade possible est un périmètre écrit avec des exclusions explicites, et une liste d'idées distincte pour les sujets reportés. Chaque ajout au périmètre doit être soumis au comité de pilotage, avec son effet sur les moyens et les risques.

L'absence de point de départ#

Le symptôme est un projet dont personne ne peut dire s'il fonctionne, parce que chacun s'appuie sur son impression. La cause est souvent une mesure jugée fastidieuse ou inutile au début. Une réponse possible, à préparer en amont : établir le point de départ mesuré avant le premier essai, avec une méthode écrite, un échantillon et une période de référence.

La démonstration prise pour une mise en service#

Le symptôme est une équipe qui annonce que le travail est terminé après une présentation réussie. La démonstration montre une possibilité, pas une fiabilité. Une réponse possible consiste à exiger le jeu d'évaluation et les critères de passage avant toute annonce.

Le projet sans propriétaire#

Le symptôme est une absence de réponse lorsqu'une erreur est signalée ou lorsque le système doit être mis à jour. La cause est fréquente : le projet est porté par l'innovation ou par la seule direction informatique, sans responsable métier ni responsable d'exploitation. Une réponse possible est de nommer ces responsables et d'inscrire la surveillance du système dans les fonctions courantes, et non dans une pile de tâches exceptionnelles.

Cadre réglementaire et règles d'usage#

Le règlement européen sur l'intelligence artificielle, souvent désigné par son appellation courte, organise l'usage des systèmes d'IA selon leur niveau de risque. Il interdit, sous réserve de vérification par un juriste, certaines pratiques jugées incompatibles avec les valeurs européennes, soumet les usages à haut risque à des exigences renforcées, impose, sous réserve de vérification par un juriste, des obligations de transparence à certains systèmes, et laisse les autres usages sous le régime des règles générales. Sans entrer dans le détail, plusieurs principes structurent ce texte et doivent guider le cadrage :

L'approche par niveau de risque : plus l'usage peut affecter les droits, la sécurité ou les décisions importantes des personnes, plus les contrôles attendus sont exigeants. Le référent risque doit donc classer le cas d'usage dès la phase de priorisation.
La transparence : les personnes doivent en principe être informées qu'elles interagissent avec un système d'IA, point à confirmer avec un juriste, et certains contenus générés doivent être identifiés comme tels.
La supervision humaine : une personne compétente devrait, sous réserve de vérification juridique, pouvoir comprendre, contrôler, corriger ou écarter le résultat, avec une véritable capacité d'intervention.
La traçabilité : les données, les versions du système et les décisions prises devraient, sous réserve de vérification juridique, pouvoir être reconstituées, notamment en cas de contestation.
La qualité des données et la robustesse : les données utilisées devraient, sous réserve de vérification juridique, être pertinentes et suffisamment fiables pour l'usage visé, et le système doit se comporter de façon stable.

Ces principes ne disent pas quelles obligations s'appliquent à un cas précis. Cela dépend du rôle de l'organisation (concevoir, acquérir, déployer ou simplement utiliser un système), du type d'usage et des données traitées. Ces obligations doivent être vérifiées avec un juriste avant la phase de preuve de concept, puis réexaminées à chaque changement d'usage. Le cadre européen de protection des données personnelles peut s'appliquer en parallèle, à confirmer avec un juriste, avec ses propres exigences de finalité, de minimisation et de droits des personnes.

Les règles pratiques d'utilisation au quotidien figurent dans la charte d'usage, dont le détail n'est pas repris dans le présent article.

Glossaire#

Cas d'usage : situation de travail précise dans laquelle une aide algorithmique peut apporter une valeur identifiable, avec un responsable et une méthode de vérification.
Périmètre : ensemble des étapes, équipes, données, décisions et risques concernés par le projet, avec ce qui est exclu.
Processus de référence : description documentée et figée de la manière actuelle de réaliser une tâche, utilisée comme base de comparaison.
Donnée de référence : version d'une information considérée comme faisant autorité pour l'ensemble de l'organisation.
Point de départ mesuré : état d'une tâche avant le projet, établi avec des indicateurs, des formules et une méthode de collecte écrits.
Preuve de concept : essai circonscrit destiné à répondre à une question de faisabilité, sans vocation à être déployé tel quel.
Passage en production : mise en service du système dans les processus réels, avec intégration, sécurité, supervision et responsabilités d'exploitation.
Dette de données : écarts accumulés entre les données disponibles et celles qui seraient nécessaires au fonctionnement fiable du cas d'usage.
Matrice valeur, faisabilité, risque : grille de lecture qui croise trois critères pour classer et prioriser les projets candidats.
Feuille de route phasée : plan découpé en phases, chacune se terminant par une décision de passage fondée sur des critères écrits.
Comité de pilotage : instance qui réunit les décideurs du projet, examine les résultats et tranche les passages d'étape.
Modèle de langage : système statistique entraîné sur de grandes quantités de texte pour produire ou transformer du texte à partir d'une demande.
Jeu d'évaluation : ensemble de cas réels dont la bonne réponse est connue, utilisé pour mesurer la qualité d'un système.
Traçabilité : capacité à reconstituer après coup les données, les versions et les décisions ayant conduit à un résultat.
Supervision humaine : contrôle exercé par une personne compétente, qui peut valider, corriger ou écarter le résultat produit par le système.
Référent risque : rôle chargé d'évaluer les conséquences d'une erreur et de définir les contrôles associés.
Responsable d'exploitation : personne qui assure le fonctionnement courant du système, répond aux incidents et pilote les mises à jour.

Checklist à imprimer#

À utiliser en fin de cadrage, puis avant chaque décision de passage à l'étape suivante.

Avant de commencer

Le besoin est formulé dans les termes du métier, et non à partir d'un outil.
La fiche de cas d'usage est rédigée et validée par le responsable métier.
Un sponsor est désigné et a accepté son rôle par écrit.

Périmètre et diagnostic

Le périmètre fonctionnel, de données, de décision et de risque est écrit, avec ses exclusions.
Le processus réel a été observé sur des dossiers réels et comparé à la procédure écrite.
Les quatre dimensions (processus, données, décisions, compétences) sont documentées.
Les données de référence sont identifiées, avec leur responsable.

Point de départ et qualité

Le point de départ mesuré repose sur une méthode, un échantillon représentatif et une période de référence.
La dette de données a été évaluée, et les dettes bloquantes sont listées.
Le jeu d'évaluation contient des cas courants et des cas difficiles.

Priorisation et gouvernance

Les trois critères (valeur, faisabilité, risque) sont qualifiés et justifiés par écrit.
Le référent risque a examiné le cas d'usage, y compris sur le plan réglementaire.
Le responsable données et le responsable d'exploitation sont nommés.
Le comité de pilotage dispose d'une fréquence, d'un ordre du jour type et d'une procédure d'urgence.

Passage à l'étape suivante

Les critères de sortie de la preuve de concept ont été écrits avant le test.
Les décisions (poursuivre, ajuster, arrêter) ont été prises et consignées.
La feuille de route indique, pour chaque phase, la décision attendue.
Un juriste a vérifié les obligations applicables au cas d'usage.

Questions fréquentes#

Faut-il un spécialiste de l'IA pour conduire le cadrage ?#

Pas nécessairement. Le cadrage est d'abord un exercice de compréhension du métier, des données et des décisions. Un profil technique est utile pour évaluer la faisabilité, mais le cœur du travail repose sur le responsable métier et le responsable données. Il est en revanche indispensable qu'une personne sache traduire les questions techniques en choix compréhensibles par le comité.

Peut-on cadrer un projet sans connaître précisément la qualité de ses données ?#

Oui, à condition que cette méconnaissance soit elle-même un résultat du cadrage. Le diagnostic des données sert justement à la mesurer. Il est en revanche risqué de lancer une preuve de concept sans avoir identifié les données de référence, car les premiers résultats seront alors difficiles à interpréter.

Faut-il commencer par un cas d'usage transverse ou par un cas propre à un métier ?#

En général, un cas d'usage propre à un métier, bien borné, est plus simple à cadrer et à évaluer. Les cas transverses, qui traversent plusieurs services, supposent une gouvernance des données déjà mature. Ils peuvent venir ensuite, lorsque les premiers apprentissages ont permis de stabiliser les définitions et les responsabilités.

Qui doit valider la sortie de la preuve de concept ?#

La décision appartient au comité de pilotage, sur la base d'un dossier écrit comprenant les résultats mesurés, la liste des dettes de données, l'avis du référent risque et celui du responsable métier. Le sponsor tranche en cas de désaccord persistant. Cette validation doit être documentée, car elle conditionne les moyens engagés ensuite.

Que faire si la preuve de concept ne donne pas les résultats attendus ?#

Un résultat décevant n'est pas un échec de la démarche. Il faut d'abord vérifier si le problème vient du système, des données, du processus ou du cas d'usage lui-même. Selon le diagnostic, le comité décide d'ajuster ou d'arrêter. Un arrêt documenté permet de réorienter les moyens vers une autre priorité et de capitaliser sur ce qui a été appris.

Conclusion#

Cadrer un projet d'intelligence artificielle revient à répondre, avant de construire, à des questions qui semblent évidentes : quel problème métier, pour qui, avec quelles données, à partir de quel point de départ, sous la responsabilité de quelles personnes et selon quelles règles. Ces questions paraissent administratives, mais elles pèsent fortement sur la qualité de la suite. Un cas d'usage bien formulé, un périmètre tenu, un processus de référence compris, une donnée de référence identifiée et une dette de données évaluée donnent au projet un socle sur lequel les décisions peuvent s'appuyer.

La preuve de concept et la mise en production doivent rester deux étapes distinctes, séparées par des critères écrits et une décision explicite. La feuille de route phasée ne suffit pas à assurer le succès, mais elle rend visible l'ordre des décisions et permet au comité de pilotage d'arrêter, d'ajuster ou de poursuivre en connaissance de cause. Le cadre réglementaire et les règles d'usage doivent accompagner ce mouvement dès le départ, avec l'appui de juristes et de référents compétents.