“Je ne suis pas technique.” C’est souvent la première chose que j’entends — ou que je me suis dit moi-même — face à un projet embarquant de l’IA. Comme si la légitimité pour piloter ce type de projet nécessitait de comprendre le fonctionnement interne d’un modèle de langage ou de savoir écrire du Python.

Ce n’est pas le cas. Et c’est précisément là où le chef de projet a un rôle irremplaçable à jouer.

Ce que “projet IA” veut dire concrètement

Un projet IA n’est pas monolithique. Derrière ce terme se cachent des réalités très différentes :

L’intégration d’une API IA existante dans un produit (ex : ajouter un chatbot GPT à un site web, intégrer une fonction de résumé automatique dans un outil interne)
Le déploiement d’un outil IA du marché (Copilot, Notion AI, outils de transcription…) dans une organisation
Le développement d’un modèle sur mesure ou le fine-tuning d’un modèle existant sur des données propriétaires
La refonte d’un processus métier autour de capacités IA (automatisation, aide à la décision, génération de contenu)

Ces quatre situations n’ont pas les mêmes enjeux, les mêmes risques, ni les mêmes profils à embarquer. Le premier travail du chef de projet : bien identifier dans quelle case on est.

Les compétences qui font la différence

Traduire entre les mondes

Un data scientist parle de précision, de rappel, de biais de données. Un directeur marketing parle de conversion, d’image de marque, de délai. Un utilisateur final parle de clarté, de rapidité, de confiance. Le chef de projet est le traducteur entre ces trois langues. Ce n’est pas une compétence technique — c’est une compétence de fond qui prend toute sa valeur dans les projets IA, où les incompréhensions entre métiers sont sources d’échecs fréquents.

Cadrer l’usage avant la solution

Le piège classique des projets IA : on choisit la technologie avant d’avoir défini le problème. Le chef de projet doit forcer le cadrage : Quel problème résout-on ? Pour qui ? Comment mesure-t-on que c’est résolu ? Ces questions basiques sauvent des projets entiers de la dérive.

Gérer l’incertitude structurelle

Les projets IA ont une caractéristique qui les distingue des projets web ou logiciels classiques : les résultats ne sont pas déterministes. Un modèle peut produire des réponses très bonnes dans 90% des cas et catastrophiques dans 10%. La gestion des risques, la définition des seuils d’acceptabilité, la communication sur les limites du système — tout ça relève du pilotage, pas du développement.

Anticiper les enjeux éthiques et réglementaires

Le règlement européen sur l’IA (AI Act) est en cours de déploiement. Les questions de RGPD sur les données d’entraînement, les biais algorithmiques, la transparence des décisions automatisées : ce sont des sujets qui arrivent sur le bureau du chef de projet bien avant d’arriver sur celui du DPO. Mieux vaut les anticiper dès le cadrage.

Une méthode adaptée : l’itération courte

Les méthodes Agile sont nées pour gérer l’incertitude logicielle. Elles sont encore plus pertinentes pour les projets IA, où on ne sait souvent pas ce que le modèle est capable de faire avant de l’avoir testé sur des données réelles.

Quelques adaptations utiles :

Inclure des “sprints de validation modèle” dans le backlog. Ce ne sont pas des sprints de développement — ce sont des itérations d’évaluation où l’équipe teste les outputs de l’IA sur des cas réels et ajuste les paramètres, les prompts ou les données.

Impliquer des utilisateurs finaux très tôt. Pas pour valider une maquette, mais pour évaluer si les outputs de l’IA leur sont utiles, compréhensibles et acceptables. La résistance à l’IA est souvent affaire de confiance, pas de fonctionnalité.

Documenter les hypothèses. Chaque décision de conception (“on suppose que le modèle sera assez précis pour ce cas d’usage”) est une hypothèse à valider. Le garder visible dans le backlog évite les mauvaises surprises en fin de projet.

Ce que j’ai appris en pratique

Piloter des projets où l’IA est un composant — pas une fin en soi — m’a appris quelques choses solides :

La clarté sur le périmètre est encore plus critique que dans un projet web classique. Les équipes techniques ont tendance à étendre le scope vers des cas d’usage “qui pourraient marcher”, et les sponsors vers des ambitions qui dépassent les capacités réelles du modèle. Tenir le cap, c’est le travail.

La communication sur les limites est un acte de management. Dire “l’IA se trompera parfois, voilà comment on gère ça” est plus crédible et plus utile que promettre une solution parfaite. Les utilisateurs qui comprennent les limites d’un outil l’adoptent mieux que ceux qui ont été déçus par une promesse excessive.

Et enfin : l’IA dans un projet, ça s’apprend en faisant. Pas besoin d’être développeur. Besoin d’être curieux, rigoureux et à l’aise avec l’ambiguïté.

En résumé

Le chef de projet qui pilote un projet IA n’a pas besoin de maîtriser les modèles. Il a besoin de comprendre les enjeux, de cadrer l’usage, de faire le lien entre les équipes et de gérer l’incertitude avec méthode. Ce sont exactement les compétences du métier — appliquées à un contexte nouveau.

C’est inconfortable au début. C’est passionnant assez vite.

Cet article conclut une série de trois sur la gestion de projet et l’UX à l’ère de l’IA.

[→ Relire l’article 1 : La gestion de projet à l’ère de l’IA, ce qui change vraiment]

[→ Relire l’article 2 : UX à l’ère de l’IA, concevoir des expériences qui restent humaines]