pauline augé.

Catégorie : Gestion de projet

  • La gestion de projet à l’ère de l’IA : ce qui change vraiment (et ce qui ne change pas)

    On entend tout et son contraire sur l’impact de l’IA dans les métiers du projet. Certains annoncent la fin du chef de projet tel qu’on le connaît. D’autres voient dans ces outils une simple amélioration du copier-coller. La réalité, comme souvent, est plus nuancée — et plus intéressante.

    Après plusieurs mois à intégrer des outils d’IA dans ma pratique quotidienne, voici ce que j’observe vraiment sur le terrain.

    Ce que l’IA change concrètement

    La production de livrables intermédiaires va beaucoup plus vite

    Compte-rendus de réunion, notes de cadrage, briefs fonctionnels, emails de relance, matrices RACI… Ces documents que l’on produit en boucle, souvent depuis des notes brouillon, sont aujourd’hui générables en quelques minutes avec une IA bien promptée.

    Ce n’est pas une révolution dans le sens du projet — c’est un gain de temps considérable sur tout ce qui n’est pas de la valeur ajoutée pure. Et ce temps récupéré, on peut le réinvestir là où ça compte : la relation client, l’arbitrage, la coordination humaine.

    La phase de recherche et de benchmark s’accélère

    Benchmarker des outils, cartographier un secteur, synthétiser de la documentation technique : des tâches qui prenaient une demi-journée se font désormais en une heure avec une IA couplée à une bonne recherche web. La condition ? Garder l’esprit critique et ne pas prendre les outputs pour argent comptant.

    La communication de projet gagne en clarté

    L’IA aide à reformuler, à adapter le niveau de discours selon l’interlocuteur (technique, métier, direction), à rendre une présentation plus percutante. Pour les profils qui jonglent entre des parties prenantes aux attentes très différentes — ce qui est le quotidien d’un chef de projet — c’est un appui précieux.

    Ce que l’IA ne remplace pas

    Le jugement de situation

    Un projet, c’est une somme de décisions dans un contexte humain et organisationnel. Savoir quand escalader, comment gérer une tension d’équipe, quand ralentir pour mieux reprendre : aucun outil ne peut remplacer cette lecture du terrain. L’IA ne connaît pas votre client, vos contraintes politiques internes, l’historique de la relation.

    La capacité à faire avancer les gens

    Motiver une équipe, débloquer un sponsor, maintenir la cohésion dans la durée — c’est du management, pas du traitement de données. L’IA peut vous aider à préparer un entretien difficile, mais elle ne le mène pas à votre place.

    La responsabilité

    À la fin, c’est le chef de projet qui signe. Qui assume les choix, les délais, les arbitrages. L’IA est un outil d’aide à la décision, pas un décideur.

    Comment intégrer l’IA sans perdre le fil

    Quelques principes que j’applique :

    Utiliser l’IA pour le premier jet, jamais pour le dernier. Tout ce qu’elle produit passe par mon regard avant de sortir. Elle génère, je valide et je reformule.

    Documenter mes prompts efficaces. Les formulations qui donnent de bons résultats pour les livrables récurrents (plan de communication, note de risques, ordre du jour…), je les garde et je les réutilise. C’est un vrai capital de productivité.

    Rester transparent avec les équipes. Si j’utilise l’IA pour préparer un document partagé, je le dis. Cela évite des malentendus et ouvre souvent une conversation utile sur les usages.

    En résumé

    L’IA ne remplace pas le chef de projet. Elle déplace son attention : moins de temps sur la production documentaire, plus de temps sur la valeur humaine du métier. Ce n’est pas rien — c’est peut-être même ce dont on avait besoin pour recentrer la fonction sur ce qui la rend irremplaçable.

    Cet article fait partie d’une série sur les pratiques du projet à l’ère numérique. [→ Lire l’article suivant : UX et IA, quand l’expérience utilisateur se réinvente]

  • Piloter un projet IA sans être développeur : le rôle clé du chef de projet

    “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]