Chef de projet IA : quelles compétences développer pour piloter un projet ?

Un chef de projet IA doit savoir cadrer un besoin métier, comprendre les données, dialoguer avec les profils techniques, organiser des tests, gérer les risques et faire adopter la solution. Il n’a pas besoin d’entraîner lui-même un modèle. En revanche, il doit poser les questions qui évitent de transformer une démonstration séduisante en projet coûteux ou inutilisable.

Ce métier se situe à l’interface. Le chef de projet traduit un problème opérationnel en exigences vérifiables, coordonne les spécialistes et aide le sponsor à prendre des décisions informées. Sa valeur vient moins de la maîtrise d’un outil précis que de sa capacité à conserver un fil logique entre l’usage, la technique et les responsabilités.

Ce qui distingue le pilotage d’un projet IA

Un projet numérique classique peut souvent être décrit par des règles déterministes : une action donnée entraîne un résultat attendu. Avec l’IA, une part d’incertitude demeure. Les performances dépendent des données, du contexte d’utilisation, du modèle choisi et de la manière dont les utilisateurs formulent leurs demandes.

Le pilotage doit donc avancer par hypothèses et par preuves. Une maquette impressionnante ne valide ni la fiabilité sur des cas difficiles, ni le coût en production, ni l’acceptation par les équipes. Le rôle consiste à organiser des décisions de poursuite, de correction ou d’arrêt, plutôt qu’à défendre le projet à tout prix.

Cette posture exige sept ensembles de compétences. Ils sont complémentaires, mais leur niveau de profondeur varie selon le projet.

1. Cadrer un cas d’usage avant de choisir la technologie

Le premier savoir-faire consiste à transformer une envie vague en problème observable. « Utiliser l’IA pour le support client » ne suffit pas. « Aider les conseillers à retrouver une procédure validée, sans répondre automatiquement au client » précise l’utilisateur, la tâche et une limite.

Le chef de projet doit pouvoir documenter la situation de départ, le résultat attendu, les personnes concernées et le coût des erreurs. Il doit aussi comparer l’IA avec une solution plus simple : amélioration du processus, moteur de recherche, règle métier ou automatisation classique.

Le livrable utile est une fiche de cadrage courte. Elle contient le périmètre, les cas exclus, un indicateur métier et les conditions d’arrêt. Le guide ADE University sur le cahier des charges d’un projet IA permet d’approfondir cette étape sans figer trop tôt l’architecture.

2. Développer une vraie culture des données

Une culture data ne signifie pas savoir administrer une base de données. Le chef de projet doit comprendre d’où viennent les informations, qui peut les utiliser, comment elles sont mises à jour et quels défauts elles contiennent. Une donnée disponible n’est pas automatiquement pertinente, licite ou représentative.

Face à un jeu de données, il doit savoir demander :

quelle période et quelle population sont couvertes ;
quelles valeurs manquent ou sont peu fiables ;
qui produit, corrige et valide les données ;
si les données de test sont séparées de celles utilisées pour concevoir la solution ;
quelles évolutions du métier pourraient dégrader les résultats.

Ces questions permettent de repérer une hypothèse fragile avant qu’elle ne devienne une dépendance technique. Elles facilitent aussi le dialogue avec les data engineers, data scientists, responsables métier et personnes chargées de la protection des données.

3. Comprendre assez la technique pour arbitrer

Faut-il savoir coder ? Pas nécessairement. Il faut toutefois maîtriser le vocabulaire qui engage le coût, les délais et les risques : modèle prédictif ou génératif, API, hébergement, latence, fenêtre de contexte, recherche documentaire, journalisation, version et surveillance en production.

Cette culture technique sert à challenger une proposition. Un prototype branché sur quelques documents ne prouve pas que la solution tiendra la charge, respectera les droits d’accès ou restera stable après un changement de modèle. Le chef de projet doit obtenir des réponses compréhensibles, faire expliciter les dépendances et traduire leurs conséquences au sponsor.

Il gagne aussi à connaître les rôles. L’expert métier définit ce qu’est une réponse utile. L’équipe data prépare et contrôle les données. Les développeurs intègrent la solution. La sécurité et le DPO interviennent selon le contexte. Le chef de projet coordonne ces contributions sans s’attribuer leur expertise.

4. Concevoir une évaluation avant le prototype

« La réponse paraît bonne » n’est pas un critère de recette. Une compétence décisive consiste à construire un protocole d’évaluation avant de voir les premières démonstrations. Il faut réunir des cas courants, des cas limites et des situations dans lesquelles le système doit s’abstenir ou transmettre la demande à une personne.

Chaque mesure doit être reliée à l’usage. Pour un assistant documentaire, on peut vérifier si la bonne source est retrouvée, si la réponse lui reste fidèle et si une information absente est signalée. Pour une extraction de documents, on mesurera chaque champ important et le temps de correction humaine. Le coût d’un faux positif peut être bien différent de celui d’un oubli.

Le cadre de gestion des risques liés à l’IA du NIST relie justement conception, utilisation et évaluation. Il est volontaire et ne remplace pas le droit européen, mais sa logique aide à traiter la fiabilité comme un travail continu.

5. Piloter par étapes et décider avec des preuves

Un planning linéaire convient mal lorsque la qualité des données ou la faisabilité reste inconnue. Le chef de projet doit découper le travail en étapes assorties d’une décision : exploration, prototype limité, évaluation, pilote avec de vrais utilisateurs, puis production.

Étape	Preuve attendue	Décision possible
Cadrage	Problème, référence actuelle et risques décrits	Explorer ou renoncer
Faisabilité	Données accessibles et approche plausible	Prototyper ou corriger le périmètre
Prototype	Résultats sur un jeu de test défini	Lancer un pilote ou arrêter
Pilote	Utilité, erreurs, coûts et retours observés	Déployer, revoir ou abandonner
Production	Surveillance, support et retour arrière prêts	Maintenir et améliorer

Cette méthode protège le budget et la crédibilité de l’équipe. Arrêter après une faisabilité négative constitue une décision utile si elle évite d’industrialiser une solution médiocre.

6. Intégrer la conformité, la sécurité et la responsabilité

La conformité ne se règle pas dans la dernière semaine. Dès le cadrage, le chef de projet doit identifier les données personnelles, les décisions qui affectent des personnes, les accès, les fournisseurs et la place du contrôle humain. Il ne remplace ni le juriste, ni le DPO, ni le responsable de la sécurité. Sa compétence consiste à les mobiliser assez tôt et à suivre leurs exigences comme de vrais livrables.

La grille d’auto-évaluation de la CNIL invite notamment à définir un objectif clair, qualifier les données, sécuriser le traitement et attribuer les responsabilités. Le règlement européen sur l’IA suit pour sa part une approche fondée sur les risques. Un projet lié au recrutement, à l’éducation, au crédit ou à un autre domaine sensible appelle donc une analyse spécifique, pas une checklist générique.

Le registre des risques doit rester vivant. Il peut suivre une fuite de données, un biais, une réponse inventée, une dépendance fournisseur, une hausse des coûts ou une dégradation après mise à jour. Pour chaque risque : un responsable, un moyen de détection, une mesure de réduction et une procédure d’escalade.

7. Faire adopter la solution sans masquer ses limites

Une solution techniquement correcte peut échouer si elle ralentit le travail, arrive sans mode d’emploi ou déplace silencieusement la charge vers les utilisateurs. La conduite du changement commence donc pendant le pilote. Les personnes concernées doivent pouvoir signaler un résultat douteux, comprendre quand reprendre la main et savoir à qui remonter un incident.

Le chef de projet doit écouter sans transformer chaque demande en fonctionnalité. Il observe les contournements, le temps de vérification et les tâches réellement facilitées. Il documente aussi les limites, car une confiance excessive est aussi dangereuse qu’un rejet systématique.

Lorsque des prestataires interviennent, cette compétence inclut la réversibilité et le transfert. Il faut conserver les jeux de test, les configurations, la documentation et la capacité à changer de solution. La grille pour internaliser ou sous-traiter un projet IA aide à répartir clairement la maîtrise et l’exécution.

Comment développer ces compétences sans se disperser ?

Le meilleur entraînement est un petit cas d’usage traité de bout en bout. Choisissez une tâche non sensible et assez précise, puis produisez les livrables du projet : fiche de cadrage, inventaire des données, jeu de tests, registre des risques, décision de poursuite et retour d’expérience utilisateur.

Travaillez ensuite les lacunes observées. Si vous ne savez pas expliquer une API ou un jeu de test, approfondissez la culture technique. Si les ateliers tournent en discussion générale, entraînez-vous à reformuler un besoin et à faire valider des critères. Si personne ne sait qui décide lors d’une erreur, concentrez-vous sur la gouvernance.

Un parcours peut combiner ressources ouvertes, exercices guidés et projet réel encadré. Le dossier sur les compétences IA en entreprise aide à distinguer le socle commun des apprentissages propres aux managers et aux fonctions expertes. Jugez votre progression sur des preuves : un cadrage relu, un test reproductible, un risque bien traité ou une décision correctement documentée.

FAQ sur les compétences du chef de projet IA

Faut-il savoir programmer pour devenir chef de projet IA ?

Le code n’est pas indispensable pour tous les postes, mais une culture technique l’est. Il faut comprendre l’architecture générale, les données, les API, les tests et les contraintes de production afin de dialoguer avec les spécialistes et d’éclairer les arbitrages. La programmation devient plus utile dans une petite équipe ou pour prototyper.

Quelle différence entre un chef de projet IA et un data scientist ?

Le data scientist travaille principalement sur les données, les méthodes d’analyse et les modèles. Le chef de projet organise le besoin, les parties prenantes, les délais, les risques et la validation. Les deux collaborent, mais leurs responsabilités ne se confondent pas.

Comment prouver ses compétences en pilotage IA ?

Un dossier de projet vaut mieux qu’une liste d’outils. Présentez le problème initial, les hypothèses, les critères d’évaluation, les risques repérés, les décisions prises et les résultats du pilote. Retirez les données confidentielles et expliquez aussi ce que vous avez refusé d’automatiser ou choisi d’arrêter.

Le bon chef de projet IA n’est pas celui qui promet que le modèle saura tout faire. C’est celui qui rend chaque étape discutable, testable et réversible, puis maintient le cap sur un usage réellement utile.

Camille Renaud, signature éditoriale d’ADE University.