La checklist de cadrage
d'un projet IA

La plupart des projets IA qui échouent ne butent pas sur la technique : ils butent sur le cadrage. On part d'un outil séduisant en quête d'un problème, on découvre trop tard que les données ne sont pas prêtes, que personne n'a pensé à la conformité ni à l'adoption, et le pilote prometteur reste bloqué à l'étape « démo qui impressionne, production qui n'arrive jamais ». Le paradoxe est cruel : au moment où l'IA n'a jamais été aussi accessible, ce qui fait la différence entre un projet qui livre et un projet qui s'enlise n'a presque rien à voir avec le modèle choisi.

Cet article vous donne la checklist à passer avant de lancer, puis déplie chaque point avec des exemples concrets tirés des métiers du système d'information. Commencez par cocher ci-dessous : chaque case franchie est un risque écarté, chaque case vide est une question à traiter avant d'engager le moindre budget.

Dix cases, dix garde-fous. Vous n'avez pas besoin de tout verrouiller au premier jour, mais vous devez pouvoir répondre honnêtement à chacune avant de lancer. Le reste de cet article déplie ces points un par un, avec ce qu'il faut vraiment vérifier et les pièges qui coûtent le plus cher.

1. Le problème avant l'outil

Imaginez entrer dans un magasin de bricolage et repartir avec la plus belle perceuse du rayon, avant même de savoir si vous avez un trou à percer ou une simple étagère à poser. C'est précisément ce que fait un projet qui démarre par l'outil : il choisit sa solution avant d'avoir posé son besoin.

C'est la règle numéro un, et pourtant la plus violée. Un projet IA sain part d'un problème métier borné, formulé sans le mot « IA » dedans. « Nos chargés de clientèle passent trois heures par jour à retrouver l'information dans quatre outils » est un problème. « On veut mettre en place un assistant IA » est une solution déguisée en objectif. La nuance n'est pas cosmétique : quand vous partez du problème, vous gardez la liberté de constater que la meilleure réponse est parfois un simple moteur de recherche, un formulaire mieux conçu ou une automatisation classique, sans IA du tout.

Le test est simple. Formulez votre projet en une phrase qui décrit un besoin et un résultat attendu mesurable. Si vous n'y arrivez pas sans nommer une technologie, c'est que vous partez de la solution. Reprenez à l'endroit : quel geste métier voulez-vous améliorer, pour qui, et à quoi verrez-vous que c'est mieux qu'avant ? Un chef de projet qui sait répondre à ces trois questions a déjà écarté la première cause d'échec.

2. Chiffrer la valeur, même grossièrement

C'est la logique du péage d'autoroute : on ne paie que si le temps gagné justifie le détour. Pour deux minutes, personne ne s'arrête au guichet ; pour une heure, tout le monde signe sans hésiter. Un projet IA se décide sur la même balance, encore faut-il avoir posé les deux plateaux.

Un projet dont personne ne sait dire ce qu'il rapporte est un projet qu'on coupera au premier arbitrage budgétaire. Chiffrer la valeur ne veut pas dire produire un business plan au centime près : cela veut dire poser un ordre de grandeur défendable. Combien de fois par mois ce geste est-il fait ? Combien de temps prend-il ? Quel est le coût d'une erreur qu'on éviterait ? Multipliez, arrondissez, assumez l'imprécision.

Prenons un exemple concret. Un business analyst estime qu'un assistant de recherche documentaire ferait gagner vingt minutes par jour à trente personnes. Vingt minutes, trente personnes, deux cents jours ouvrés : cela fait deux mille heures par an. Même en divisant ce chiffre par deux pour rester prudent, l'ordre de grandeur justifie largement un pilote. À l'inverse, si le calcul donne quelques dizaines d'heures par an, la question n'est pas « comment le faire » mais « faut-il le faire ». Chiffrer la valeur avant de lancer, c'est se donner le droit de dire non à temps, et le moyen de prouver le oui après le pilote.

3. Les données : le vrai goulot d'étranglement

Vous pouvez avoir la recette la plus brillante : si le frigo est vide ou rempli d'ingrédients périmés, le grand dîner n'aura pas lieu. En IA, le modèle est la recette, les données sont les ingrédients, et la qualité du plat tient d'abord à la matière première, pas au talent du chef.

Dans neuf projets IA sur dix, le point de blocage n'est pas le modèle, ce sont les données. Un projet peut être parfaitement cadré côté métier et parfaitement pertinent, et mourir parce que les données nécessaires n'existent pas, sont éparpillées dans des systèmes qui ne se parlent pas, sont de trop mauvaise qualité pour être exploitables, ou ne peuvent pas être utilisées pour des raisons de droits ou de confidentialité. Vérifier la disponibilité réelle des données avant de lancer évite le scénario le plus démoralisant : investir des semaines pour découvrir que la matière première manque.

Quatre questions à poser systématiquement. Les données existent-elles vraiment, et pas seulement en théorie ? Sont-elles accessibles, dans un format exploitable, sans un chantier d'intégration disproportionné ? Leur qualité est-elle suffisante, ou sont-elles truffées de trous, de doublons et d'incohérences qui fausseraient tout ? Et enfin, avez-vous le droit de les utiliser pour cet usage, au regard du RGPD et des engagements pris envers vos clients ? Un data analyst qui répond à ces quatre questions dès le cadrage fait gagner un temps considérable au reste de l'équipe.

4. La sensibilité des données : traiter la confidentialité tôt

Confier un double de ses clés n'engage pas au même niveau selon ce qu'il y a derrière la porte : une clé banale suffit pour laisser entrer le livreur, mais l'accès au coffre-fort réclame un contrat, une identité vérifiée et des garanties écrites. Les données que vous confiez à un outil d'IA obéissent à la même règle de proportion.

Confier des données à un outil d'IA, c'est parfois les envoyer à un tiers. Cette réalité toute simple doit être posée au cadrage, pas découverte au moment du déploiement. Les données personnelles sont-elles concernées ? Faut-il les anonymiser ou les pseudonymiser avant traitement ? L'outil retenu offre-t-il des garanties contractuelles sur le fait qu'il n'utilisera pas vos données pour s'entraîner ? Ces questions décident souvent du choix de la solution : un usage sur des données clients confidentielles ne s'accommode pas du même outil qu'un brouillon de note interne.

La bonne pratique consiste à classer, dès le départ, le niveau de sensibilité des données en jeu. Une note de réunion interne banale n'appelle pas la même vigilance qu'un dossier RH ou qu'une base de données médicale. Cette classification oriente tout le reste : le choix build/buy, le niveau de conformité, l'architecture. La négliger, c'est risquer de devoir tout refaire quand le DPO ou la sécurité découvrent le projet à la dernière minute.

5. Build, buy ou adapter : trancher avant de coder

Pour s'habiller, on prend du prêt-à-porter quand le besoin est courant, on passe chez le tailleur quand il faut que ça tombe juste, et on ne fait coudre sur mesure de zéro que pour une occasion où rien d'existant ne convient. L'arbitrage entre acheter, adapter et construire une solution IA suit exactement la même logique.

Faut-il acheter une solution du marché, adapter une brique existante à vos données, ou construire de zéro ? Cet arbitrage structure le budget, le délai et le niveau de dépendance pour des années. Le réflexe sain : acheter pour un besoin standard, adapter quand vous avez besoin de vos propres données ou de vos propres règles, et ne construire de zéro que lorsque l'IA touche votre cœur de métier et qu'aucune solution existante ne convient. Comparez les trois voies sur un cas réel avant de vous engager.

Le piège classique consiste à sous-estimer le coût du « run ». Construire coûte cher, mais maintenir coûte plus cher encore, et ce coût-là dure aussi longtemps que le service. Un architecte SI qui intègre le coût total de possession (build et run) dans l'arbitrage évite le mirage du « on va le faire nous-mêmes, ça reviendra moins cher ».

6. La conformité : un critère de conception, pas une case finale

Personne ne coule les fondations d'une maison une fois les murs montés : on les prévoit avant, sous peine d'un chantier ruineux, quand il n'est pas carrément impossible. La conformité d'un projet IA joue exactement ce rôle de fondation, à poser au début et non à la fin.

Le règlement européen sur l'IA classe les usages par niveau de risque, du minimal à l'inacceptable, en passant par le risque limité (obligation de transparence) et le haut risque (documentation, journalisation, supervision humaine). Identifier où tombe votre usage avant de lancer change parfois la conception de fond en comble : un outil qui pèse sur une décision touchant des personnes (recrutement, crédit, accès à un service) impose un socle d'exigences qu'on ne bricole pas après coup. Ajoutez le RGPD, la sécurité, l'accessibilité et la traçabilité des décisions, et vous avez la carte de conformité de votre projet.

La bonne nouvelle : un système bien pensé au départ est conforme presque par construction. Prévoir un point de contrôle humain, une journalisation et des données propres dès le schéma d'architecture coûte bien moins cher que de les rajouter sur un système déjà en production. La conformité n'est pas un frein au projet, c'est une contrainte de conception parmi d'autres, à condition de la poser tôt. Un product owner qui traduit ces obligations en critères d'acceptation testables (« la mention IA est visible », « un humain peut contester la décision ») les rend concrètes pour toute l'équipe.

7. Le critère de succès : décider à l'avance ce que « ça marche » veut dire

Une course à pied sans ligne d'arrivée tracée n'a pas vraiment de vainqueur : chacun peut se déclarer premier, et au fond personne ne l'est. Le critère de succès d'un projet, c'est cette ligne blanche peinte au sol avant le départ.

Un projet sans critère de succès défini à l'avance est un projet qu'on n'arrête jamais et qu'on ne réussit jamais vraiment, parce que la barre bouge au gré des impressions. Avant de lancer, écrivez noir sur blanc à quoi vous verrez que ça fonctionne : un seuil de précision, un temps de traitement, un taux d'adoption, un niveau de satisfaction. Ce critère doit être mesurable et fixé avant de voir les résultats, sinon vous finirez par déclarer victoire sur ce qui aura bien voulu marcher.

Associez-y un plan de test simple : sur quel échantillon, avec quels utilisateurs, sur quelle durée, et qui juge ? Un critère de succès sans plan de test reste une intention. Les deux ensemble transforment le pilote en expérience qui tranche, au lieu d'une démo qui séduit sans rien prouver.

8. L'adoption : la moitié du travail que tout le monde oublie

Une salle de sport flambant neuve installée dans les locaux ne fait maigrir personne tant que les gens n'y entrent pas : les machines dernier cri ne créent pas l'usage à elles seules. Un outil d'IA livré sans accompagnement subit exactement le même sort.

Un outil que personne n'utilise ne vaut rien, quelle que soit sa qualité technique. L'adoption est la moitié invisible du projet, celle qu'on découvre trop tard quand l'outil livré prend la poussière parce que les utilisateurs n'ont pas été embarqués, formés, ni convaincus. Prévoir l'adoption au cadrage, c'est se demander dès le départ : qui va s'en servir concrètement, dans quel geste de travail cela s'insère-t-il, qui accompagne la prise en main, et comment lève-t-on les résistances légitimes ?

La conduite du changement n'est pas un supplément d'âme réservé aux grands programmes. Même un petit outil a besoin d'un référent enthousiaste, d'une démonstration sur des cas réels, et d'un canal pour remonter les frictions. Les projets qui réussissent leur adoption sont ceux qui impliquent les futurs utilisateurs avant le lancement, pas ceux qui leur livrent un outil fini en espérant qu'ils l'adoptent par magie.

9. Le pilote borné : prouver avant d'industrialiser

Un cuisinier goûte une cuillère de sauce avant de servir : si c'est trop salé, il le découvre pour une bouchée, pas pour un banquet de cinquante couverts déjà dressé. Le pilote joue ce rôle de cuillère pour un projet IA.

Le pilote (ou proof of concept) est votre assurance contre l'industrialisation d'une mauvaise idée. Un bon pilote a trois caractéristiques : un périmètre réduit (un cas d'usage, une équipe), une durée fixe (souvent quatre à huit semaines), et une décision go/no-go explicite à la clé. Son but n'est pas de faire une belle démo, mais de répondre à une question de risque précise : les données suffisent-elles ? les utilisateurs adoptent-ils ? la valeur est-elle réellement au rendez-vous ?

Le piège, ici, s'appelle le pilote zombie : un projet lancé « pour voir », sans critère de sortie, qui ne meurt jamais et ne passe jamais en production. Il consomme du budget et de l'énergie sans jamais trancher. La discipline du pilote borné, avec une date de fin et une décision à prendre, évite cette dérive. Si le pilote échoue, c'est une bonne nouvelle : vous l'avez appris pour quelques semaines d'effort au lieu de plusieurs mois d'industrialisation.

10. Le référent et la gouvernance : nommer qui décide

Un immeuble sans syndic ne pose aucun problème tant que tout va bien ; le jour où une canalisation lâche, personne ne sait qui appelle le plombier, qui règle la facture ni qui répond aux voisins. Un projet IA sans référent ni gouvernance vit dangereusement de la même manière.

Un projet sans propriétaire clair est un projet orphelin. Avant de lancer, nommez un référent qui porte le projet, et posez la gouvernance : qui décide des arbitrages, qui audite les résultats et la conformité, qui rend compte auprès de la direction ? Sur un usage sensible, cette question devient centrale : en cas de contrôle ou d'incident, quelqu'un doit pouvoir expliquer les choix faits et assumer la responsabilité de l'usage.

La gouvernance n'a pas besoin d'être lourde. Sur un petit projet, un référent nommé et une revue régulière suffisent. L'essentiel est que ces rôles existent explicitement, avant le lancement, plutôt que de se découvrir dans l'urgence le jour où une question difficile se pose. Le DSI, garant de la vue d'ensemble, a tout intérêt à ce que chaque projet IA ait son référent identifié dès le cadrage.

Ce que chaque métier du SI doit vérifier

La checklist parle à toute la chaîne, mais chaque rôle a son point de vigilance propre. Voici, pour huit profils typiques d'une DSI, le réflexe de cadrage à intégrer avant de lancer.

• DSI. S'assurer que chaque projet a un problème métier réel, un référent nommé et une gouvernance, et que le portefeuille de projets IA reste cohérent avec la stratégie et les moyens.
• Chef de projet. Passer la checklist au complet avant tout lancement, borner le pilote avec une décision go/no-go, et refuser de démarrer un projet dont les données ou la valeur ne sont pas vérifiées.
• Product owner. Traduire le critère de succès et les obligations de conformité en critères d'acceptation testables, et porter la voix des futurs utilisateurs dans le cadrage.
• Business analyst. Formuler le problème côté métier, chiffrer la valeur attendue, et repérer dès l'atelier si l'usage vise à décider sur des personnes (signal de conformité renforcée).
• Data analyst. Vérifier l'existence, l'accessibilité, la qualité et les droits d'usage des données avant que le projet n'avance, et documenter ce qui manque.
• Architecte SI. Instruire l'arbitrage build/buy/adapter, intégrer le coût du run, et concevoir la journalisation et le point de reprise humaine dès le schéma.
• Devops. Anticiper le déploiement, la sécurité des données confiées et le coût d'exploitation, pour que le passage du pilote à la production ne soit pas une falaise.
• Développeur. Signaler tôt les impasses techniques et les usages qui glissent vers une décision automatisée sur des personnes, et implémenter les garde-fous prévus (transparence, supervision).

Aucun de ces réflexes ne demande d'être un expert de l'IA. Chacun demande de reconnaître, dans son propre travail, le moment où une question de cadrage se pose. C'est une compétence qui se travaille sur des cas concrets, bien plus qu'une procédure à appliquer mécaniquement.

Les cinq erreurs de cadrage les plus fréquentes

À force de voir des projets IA s'enliser, on repère des schémas. Voici les cinq pièges qui reviennent le plus souvent, et le réflexe qui les désamorce.

• Partir de l'outil. « On a vu une démo impressionnante, on veut la même. » Le projet cherche ensuite un problème à résoudre, et le trouve rarement. Antidote : partir du problème métier, toujours.
• Ignorer les données jusqu'au développement. On cadre tout, on lance, et on découvre que la donnée nécessaire n'existe pas ou est inexploitable. Antidote : vérifier la disponibilité réelle des données au cadrage.
• Ne jamais chiffrer la valeur. Le projet avance par enthousiasme, puis tombe au premier arbitrage budgétaire faute de justification. Antidote : poser un ordre de grandeur défendable avant de lancer.
• Découvrir la conformité à la fin. Le système est en production quand le DPO ou la sécurité s'en mêlent, et il faut tout reprendre. Antidote : classer le niveau de risque et de sensibilité dès la conception.
• Oublier l'adoption. L'outil est livré, techniquement parfait, et personne ne s'en sert. Antidote : embarquer les futurs utilisateurs avant le lancement, pas après.

Testez votre réflexe de cadrage

Un cas concret vaut mieux qu'un long exposé. Mettez-vous en situation de lancement de projet.

Le vocabulaire du cadrage, retourné

Quelques termes reviennent sans cesse en réunion de lancement et servent parfois à impressionner plutôt qu'à clarifier. Voici les principaux, décodés en une phrase. Cliquez une carte pour la retourner.

Les six étapes du cadrage, en un coup d'œil

Le réflexe : le problème avant l'outil

Si vous ne devez retenir qu'une ligne de cet article : ne partez jamais d'une technologie. Partez d'un problème métier borné, vérifiez que les données suivent, chiffrez la valeur attendue, cadrez la conformité dès le début, et prouvez le tout sur un pilote court avant d'industrialiser. La technique est rarement le facteur limitant. Le cadrage, presque toujours. Une checklist ne remplace pas le jugement, mais elle vous force à poser les bonnes questions au bon moment, quand elles coûtent encore une conversation et pas un projet entier.