i

Description

Un petit robot à roues omnidirectionnelles équipé d'un bras articulé

Source

Anani A. George · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

L'IA au service de la conduite de projet (général puis data)

Vous saurez où une IA générative (assistant conversationnel, copilote intégré aux outils, agent) apporte un gain réel dans la conduite d'un projet : cadrage, backlog, estimation…

En bref

• Vous saurez où une IA générative (assistant conversationnel, copilote intégré aux outils, agent) apporte un gain réel dans la conduite d'un projet : cadrage, backlog, estimation, planification, risques, comptes rendus, rétrospectives, recette, documentation, pilotage.
• Vous disposerez d'un tableau gain / risque / maturité (/5) par activité, pour décider où investir en premier et où s'abstenir.
• Vous verrez ce qui change sur un projet data (chiffres, qualité, volumétrie, confidentialité) et pourquoi l'IA y est plus utile pour structurer que pour décider.
• Vous repartirez avec des garde-fous opérationnels, une dizaine de prompts réutilisables et une liste de ce que l'IA ne remplace pas.

Les notes de ce fichier sont des appréciations d'expert, contextuelles (équipe de 4 à 12 personnes, projet BI/datamart, outils du marché actuels). Voir NOTATION. Les capacités des modèles et des copilotes évoluent vite : tout ce qui touche aux fonctionnalités d'un produit précis est « à revérifier ».

Sur cette page

1. 1. Cadre et mise en garde
   1. 🟢 Novice — de quoi parle-t-on ?
   2. 🟡 Pratique — pourquoi la conduite de projet est un bon terrain
   3. 🔴 Expert — état de l'art et volatilité
2. 2. Les bases de la collaboration avec une IA
   1. 🟢 Novice — quatre réflexes
   2. 🟡 Pratique — le cycle « produire, contester, valider »
   3. 🔴 Expert — ingénierie de contexte plutôt qu'ingénierie de prompt
3. 3. Activité par activité
   1. 3.1 Cadrage et vision
   2. 3.2 Backlog, user stories et critères d'acceptation
   3. 3.3 Estimation
   4. 3.4 Planification
   5. 3.5 Risques
   6. 3.6 Comptes rendus et communication
   7. 3.7 Rétrospectives et amélioration continue
   8. 3.8 Recette et qualité
   9. 3.9 Documentation
   10. 3.10 Pilotage et reporting
4. 4. Tableau de synthèse gain risque maturité
5. 5. Le cas particulier des projets data
   1. 🟢 Novice — pourquoi la data change la donne
   2. 🟡 Pratique — où l'IA aide le plus
   3. 🔴 Expert — les arbitrages propres à la data
6. 6. Garde-fous
   1. 🟡 Pratique — dix règles opérationnelles
   2. 🔴 Expert — gouvernance et cadre réglementaire
7. 7. Exemples de prompts
8. 8. Ce qui reste humain
9. 9. Mesurer le gain réel
   1. 🟡 Pratique — mesurer localement
   2. 🔴 Expert — éviter les illusions de productivité
10. 10. Pièges liés à une IA mal cadrée
11. 11. Voir aussi

Niveau : 🟢→🔴

1. Cadre et mise en garde#

🟢 Novice — de quoi parle-t-on ?#

Une IA générative (voir GLOSSAIRE) produit du texte, du code ou des tableaux à partir d'une consigne. Elle est statistiquement brillante pour la forme et structurellement faillible sur le fond : elle rédige un compte rendu impeccable… parfois avec une décision que personne n'a prise. Trois familles d'usage se côtoient :

Plus on descend dans le tableau, plus le gain potentiel et le risque grandissent ensemble. La conduite de projet est un terrain favorable aux deux premières familles (beaucoup de texte, de synthèse, de structuration), et un terrain à haut risque pour la troisième (les effets de bord touchent des personnes, des engagements, des budgets).

🟡 Pratique — pourquoi la conduite de projet est un bon terrain#

Le travail de conduite de projet est dominé par du travail de langage : écrire une vision, reformuler un besoin, découper, résumer, relancer, rendre compte. Une IA y excelle sur trois gestes : structurer (transformer du vrac en plan), transformer (d'un format à un autre : notes → compte rendu, mail → ticket), challenger (« que manque-t-il à ce cadrage ? »). Elle est médiocre pour savoir (les faits propres à votre projet), décider, engager et chiffrer sans données.

🔴 Expert — état de l'art et volatilité#

• Les modèles de langage actuels savent tenir de longs contextes, manipuler des tableaux et produire du code fonctionnel ; ils restent sujets aux hallucinations (affirmations plausibles et fausses), à la complaisance (tendance à abonder dans le sens du demandeur) et à la non-reproductibilité (deux exécutions, deux textes).
• Les fonctionnalités intégrées aux outils de gestion (génération de tickets, résumés d'itération, assistants de planification) existent chez la plupart des éditeurs, avec des licences, des périmètres de données et des états « preview/GA » changeants. Ne pas figer un choix d'outil sur la foi d'un tableau daté : vérifier chez l'éditeur. Voir IA et outils pour le versant outils et synthèse transverse IA pour la vue d'ensemble.
• Aucun chiffre de « gain de productivité » général n'est donné ici : les études publiées sont partielles, sectorielles et souvent financées par les éditeurs. Seule la mesure locale (§9) fait foi.

2. Les bases de la collaboration avec une IA#

🟢 Novice — quatre réflexes#

1. Donner le contexte : rôle, public, objectif, format attendu, contraintes. Un prompt de deux lignes donne un texte générique.
2. Fournir la matière : l'IA ne connaît pas votre projet. Collez les notes, le périmètre, la définition de « terminé » (voir Scrum cadre).
3. Demander une structure vérifiable : tableau, liste numérotée, critères d'acceptation, plutôt qu'un paragraphe fluide qui masque les trous.
4. Relire comme on relit un stagiaire brillant et pressé : plausible n'est pas exact.

🟡 Pratique — le cycle « produire, contester, valider »#

Une utilisation mûre suit trois temps : (1) l'IA produit un premier jet à partir de votre matière ; (2) vous demandez une contre-lecture adverse (« quelles objections un DSI sceptique ferait-il ? », « quelles stories violent INVEST ? ») ; (3) un humain valide et signe. L'étape 2 est celle qui rapporte le plus : l'IA est un excellent contradicteur de bon marché, à condition de lui demander explicitement de ne pas être aimable.

🔴 Expert — ingénierie de contexte plutôt qu'ingénierie de prompt#

Avec des fenêtres de contexte larges, le levier n'est plus la formule magique mais ce que l'on met dans le contexte : charte du projet, DoD, glossaire, exemples de bonnes stories de l'équipe, décisions antérieures. Un dossier de contexte versionné (un fichier texte maintenu comme du code : vision, vocabulaire, conventions de nommage, exemples « bon / mauvais ») améliore davantage les sorties que n'importe quelle astuce de formulation. C'est aussi un actif de gouvernance : on sait ce que l'IA a su quand elle a produit tel texte.

3. Activité par activité#

Chaque activité suit le même fil : ce que l'IA apporte, comment s'y prendre, ce qu'il faut vérifier. Les notes chiffrées sont regroupées au §4.

3.1 Cadrage et vision#

🟢 Apport. Aider à écrire une note de cadrage, un elevator pitch, un périmètre « dedans / dehors », une liste de parties prenantes. L'IA est utile pour ne pas oublier des rubriques (hypothèses, contraintes, critères de succès, risques).

🟡 Méthode. Partir d'un entretien ou de notes brutes ; demander une note de cadrage en 1 page, puis une liste de questions ouvertes (ce qui manque). Les questions ouvertes ont plus de valeur que le texte : elles préparent le prochain atelier avec le sponsor. Voir Fondamentaux (valeur, cas d'affaires) et Choisir sa méthode.

🔴 Vérifier. L'IA invente volontiers des critères de succès chiffrés et des « gains attendus » : tout chiffre non sourcé est une hypothèse, pas un objectif. Le cas d'affaires reste porté par le sponsor.

3.2 Backlog, user stories et critères d'acceptation#

🟢 Apport. Transformer un besoin exprimé en phrase libre en story au format « En tant que… je veux… afin de… » avec critères d'acceptation en Given/When/Then. Détecter des stories trop grosses, ambiguës ou non testables (voir INVEST dans Scrum en pratique).

🟡 Méthode. Fournir 3 stories exemplaires de l'équipe (few-shot) + la DoD ; demander des stories verticales (voir le découpage) et des critères d'acceptation vérifiables par une requête. Pour le data, utiliser le modèle de Scrum et data (story de donnée : source, grain, règle, contrôle).

🔴 Vérifier. L'IA produit des stories homogènes et plausibles mais déconnectées de la réalité des sources : elle ne sait pas que la table de faits n'a pas de clé naturelle, ou que la source est rechargée à 4 h. Une story n'est pas bonne parce qu'elle est bien écrite : elle l'est si l'équipe peut la réaliser et le métier la recetter.

3.3 Estimation#

🟢 Apport. Peu de gain direct sur le chiffre lui-même : l'IA n'a pas vos données de flux. Elle aide à lister ce qui est oublié (tests, migration, documentation, recette, déploiement) et à comparer avec des stories passées si on lui fournit l'historique.

🟡 Méthode. Donner l'historique (cycle time par type de story, voir la prévision par le flux dans Scrum en pratique) et demander une fourchette avec hypothèses, ou une simulation de type Monte-Carlo sur les temps de cycle (l'IA écrit le script, vous exécutez sur vos données). Éviter « estime cette story en points » : la réponse est un nombre sans fondement.

🔴 Vérifier. Un chiffre produit par une IA ressemble à une estimation d'équipe mais n'en a pas la propriété essentielle : l'engagement partagé. Et il sert d'ancre (biais) : une fois lu, les humains s'en éloignent peu. Estimer d'abord à l'aveugle, comparer ensuite.

3.4 Planification#

🟢 Apport. Construire un planning de jalons à partir d'une liste de lots et de dépendances, repérer le chemin critique, proposer un séquencement de releases. Convertir un plan d'un format à un autre (tableau → diagramme de Gantt Mermaid, voir Outils de planification).

🟡 Méthode. Donner les contraintes dures (dates de fenêtre de livraison, congés, dépendance à un tiers) et demander les conflits plutôt que le plan : « quelles dépendances rendent ce planning intenable ? ». Pour le planning de Sprint, voir Scrum en pratique.

🔴 Vérifier. L'IA lisse : elle propose des plannings trop réguliers, sans aléas ni marge. Ajoutez explicitement :« propose un scénario pessimiste fondé sur les risques listés ». Les dépendances implicites (un environnement partagé, une personne clé) ne sont connues que de l'équipe.

3.5 Risques#

🟢 Apport. Brainstorming de risques à partir d'une description de projet : l'IA est un bon générateur d'exhaustivité (techniques, organisationnels, données, juridiques). Elle aide à formuler « cause → événement → conséquence » proprement.

🟡 Méthode. Technique du pre-mortem assisté : « nous sommes dans 6 mois, le projet a échoué ; rédige les 10 causes les plus probables, par catégorie ». Puis l'équipe note probabilité et impact, et définit les réponses (éviter, atténuer, transférer, accepter, voir Fondamentaux). Pour les risques data, voir Pièges et bonnes pratiques.

🔴 Vérifier. Le registre produit est générique : il pourrait s'appliquer à n'importe quel projet. Le test : un risque est utile s'il a un propriétaire, un déclencheur observable et une action datée. L'IA ne les fournit pas.

3.6 Comptes rendus et communication#

🟢 Apport. Transformer une transcription ou des notes en compte rendu : décisions, actions (qui, quoi, quand), points ouverts. C'est l'usage au meilleur rapport gain/risque de toute la liste.

🟡 Méthode. Imposer un gabarit (décisions / actions / risques / questions) et demander de citer la phrase source de chaque décision. Faire valider le compte rendu par un participant dans les 24 heures. Adapter la communication à l'audience : même contenu, version comité de pilotage (5 lignes) et version équipe (détails).

🔴 Vérifier. Trois dérives classiques : décision inventée (une hypothèse discutée présentée comme actée), attribution fautive (l'action est mise sur le mauvais nom, surtout avec une transcription mal diarisée), gommage du désaccord (le résumé lisse un conflit qui doit rester visible). Un enregistrement de réunion implique en outre consentement et conservation (voir §6).

3.7 Rétrospectives et amélioration continue#

🟢 Apport. Préparer des formats d'animation, regrouper des post-its par thème, faire ressortir des motifs récurrents sur plusieurs rétros (« la recette est citée dans 5 rétros sur 7 »). Voir Scrum en pratique pour les formats.

🟡 Méthode. Alimenter l'IA avec les comptes rendus de rétros anonymisés des 6 derniers sprints ; demander les actions promises non réalisées et les sujets qui reviennent. C'est de la mémoire collective outillée.

🔴 Vérifier. Ne jamais substituer l'IA au temps de parole : la rétrospective est un rituel d'équipe. Et ne pas lui faire analyser des données sensibles sur des personnes (ressenti individuel, performance) sans cadre explicite.

3.8 Recette et qualité#

🟢 Apport. Générer des cas de test à partir de critères d'acceptation, des jeux de données de test synthétiques, des scénarios de bord (valeurs nulles, doublons, fuseaux horaires, caractères accentués).

🟡 Méthode. Demander à l'IA des requêtes de contrôle (comptages, sommes de contrôle, rapprochements source/cible) à exécuter, plutôt qu'un verdict « les chiffres sont bons ». Elle ne voit pas vos données : elle écrit le contrôle, c'est la base qui répond.

🔴 Vérifier. La recette métier d'un chiffre ne se délègue pas : un utilisateur qui dit « ce chiffre est juste » engage sa fonction. L'IA peut préparer le protocole (voir Scrum et data, cinq niveaux de contrôle), pas porter la conclusion.

-- Exemple de requête de contrôle que l'IA peut rédiger (à valider avant usage) :
-- rapprochement du chiffre d'affaires mensuel entre la table de faits et la source
SELECT  d.annee_mois,
        SUM(f.montant_ht)                               AS ca_datamart,
        s.ca_source,
        SUM(f.montant_ht) - s.ca_source                 AS ecart
FROM    dm.FACT_VENTE        AS f WITH (NOLOCK)
JOIN    dm.DIM_DATE          AS d WITH (NOLOCK) ON d.date_id = f.date_id
JOIN    (SELECT FORMAT(date_facture,'yyyy-MM') AS annee_mois, SUM(montant_ht) AS ca_source
         FROM   staging.FACTURE WITH (NOLOCK)
         GROUP  BY FORMAT(date_facture,'yyyy-MM')) AS s ON s.annee_mois = d.annee_mois
GROUP BY d.annee_mois, s.ca_source
HAVING  ABS(SUM(f.montant_ht) - s.ca_source) > 0.01;   -- tout écart non nul est une anomalie à expliquer

3.9 Documentation#

🟢 Apport. Rédiger ou mettre à jour de la documentation à partir de sources fiables : dictionnaire de données depuis le schéma, notes de version depuis la liste des tickets, guide d'installation depuis les scripts. L'IA est excellente pour la documentation dérivée (du code vers le texte).

🟡 Méthode. Fournir le schéma réel (DDL, métadonnées) et demander la description fonctionnelle de chaque colonne marquée « à valider par le métier » quand l'intention n'est pas déductible. Voir Méthodes spécifiques data (gouvernance, DAMA) et le thème métadonnées de la matrice projet data.

🔴 Vérifier. La documentation générée vieillit mal si elle n'est pas régénérable : préférer un pipeline qui la reproduit à chaque version, comme du code. Et ne jamais publier un texte généré sans signature explicite de sa nature (voir §6).

3.10 Pilotage et reporting#

🟢 Apport. Synthétiser un tableau de bord en commentaire de gestion, repérer des tendances (flux ralenti, dette croissante), préparer des questions pour le comité.

🟡 Méthode. Fournir des données exportées (burndown, cycle time, nombre de défauts) et demander une lecture et des hypothèses d'explication à vérifier. Voir Métriques et reporting de projet et les métriques DORA dans CI/CD.

🔴 Vérifier. L'IA interprète trop vite : une corrélation devient une cause, une baisse de vélocité un « problème d'équipe ». Elle est aussi un amplificateur de la loi de Goodhart : si l'on pilote sur des indicateurs, elle aidera à les optimiser au lieu de questionner leur pertinence.

4. Tableau de synthèse gain risque maturité#

Contexte : équipe de 4 à 12 personnes, projet BI/datamart de 6 à 18 mois, assistant conversationnel d'entreprise (données non entraînantes, voir §6). Gain : économie de temps et de qualité attendue, 5 = très élevé. Risque : conséquence d'une erreur non détectée, 5 = très élevé. Maturité : fiabilité et recul de l'usage aujourd'hui, 5 = pratique établie.

Lecture : le gain est maximal là où la tâche est transformer du texte existant, et décroît à mesure que la tâche demande de savoir des choses propres au projet ou d'engager quelqu'un. Le risque suit la courbe inverse.

5. Le cas particulier des projets data#

🟢 Novice — pourquoi la data change la donne#

Sur un projet data, la matière du projet est elle-même de la donnée — souvent confidentielle (clients, salariés, chiffres commerciaux) et dont l'exactitude est le produit. Trois conséquences : (1) ce qu'on colle dans un assistant peut être une donnée à caractère personnel ; (2) un chiffre faux généré est plus dangereux qu'un texte maladroit ; (3) l'IA ne voit pas la base : elle n'a que ce qu'on lui montre.

🟡 Pratique — où l'IA aide le plus#

🔴 Expert — les arbitrages propres à la data#

• Données personnelles. Ne jamais envoyer à un service externe des données personnelles sans base juridique, contrat de sous-traitance et analyse d'impact quand elle s'impose (RGPD). La parade structurelle : travailler sur schéma, métadonnées et données synthétiques, jamais sur données brutes. Voir le thème sécurité/conformité de la matrice projet data.
• Qualité. L'IA peut proposer des règles de qualité à partir de profils statistiques (valeurs distinctes, taux de nuls). Elle ne sait pas distinguer une anomalie d'une particularité légitime du métier : la règle est validée par le propriétaire de la donnée. Voir qualité des données.
• Traçabilité. Un script ou une mesure assistés par IA doivent être traçables : ticket, revue, test. Ce qui a été généré ne dispense pas du cycle normal (commit, revue, déploiement par pipeline).
• Versions de modèle. Un modèle de langage change sans préavis ; deux mois plus tard, la même consigne donne un autre résultat. Pour un usage industrialisé (génération automatique de documentation à chaque version), épingler la version du modèle, tester les sorties sur un jeu de référence, et traiter le changement de modèle comme un changement de dépendance.
• Agents sur la donnée. Un agent qui exécute des requêtes sur un datamart doit disposer d'un compte en lecture seule, limité à un schéma, avec journalisation : le principe du moindre privilège s'applique à l'IA comme à un stagiaire.

6. Garde-fous#

🟡 Pratique — dix règles opérationnelles#

1. Classer les données avant tout usage : public, interne, confidentiel, personnel. Seul le niveau autorisé est collé dans l'outil autorisé.
2. Choisir un outil encadré : contrat d'entreprise, absence d'entraînement sur les données soumises, hébergement et rétention connus (à vérifier chez l'éditeur). Pas de comptes personnels pour du travail de l'entreprise.
3. Anonymiser ou synthétiser : remplacer noms, identifiants, montants réels par des valeurs fictives cohérentes.
4. Un humain responsable par livrable : le nom sur le document est celui d'une personne, pas de l'outil.
5. Signer les contenus générés quand ils sont publiés (wiki, Confluence, documentation) : mention « Rédigé par une IA, relu par X ». Un texte généré qui passe pour écrit de la main d'un collègue fausse la confiance.
6. Tracer les consignes importantes (prompts de production, dossier de contexte) dans le dépôt, comme on trace un script.
7. Valider par exécution ce qui peut l'être : le SQL tourne sur une base de test, la mesure est vérifiée sur un cas chiffré, le script est rejoué deux fois.
8. Interdire les actions irréversibles sans validation : envoi de mails, création massive de tickets, modification de données.
9. Obtenir le consentement pour l'enregistrement et la transcription de réunions ; informer les participants de l'usage et de la conservation.
10. Mesurer (§9) et réviser la politique tous les trimestres : l'outil, les risques et la réglementation bougent.

🔴 Expert — gouvernance et cadre réglementaire#

• Règlement européen sur l'IA (AI Act) : il instaure des obligations graduées selon le risque et des exigences de transparence ; leur calendrier d'application est échelonné et a été en partie reporté pour les systèmes à haut risque par le volet « omnibus numérique ».L'usage interne d'un assistant pour de la gestion de projet relève généralement de risques faibles, mais tout usage touchant les personnes (évaluation de performance, recrutement, surveillance) change de catégorie. Statut précis et dates : à vérifier auprès de la direction juridique.
• Propriété intellectuelle et licences : du code généré peut ressembler à du code sous licence ; vérifier les conditions de l'éditeur et la politique de l'entreprise.
• Biais : un résumé de réunion peut favoriser les voix les plus présentes dans la transcription ; une priorisation proposée peut refléter les biais du modèle. Contre-lecture humaine systématique.
• Séparation des rôles : l'IA qui rédige ne doit pas être celle qui valide ; garder au moins un humain indépendant entre les deux.

7. Exemples de prompts#

Chaque prompt est un point de départ à adapter ; les crochets désignent ce que vous fournissez. Aucun ne dispense de relecture.

P1 — Note de cadrage et questions ouvertes (🟢)

Tu es un chef de projet data expérimenté. À partir des notes ci-dessous, rédige une note de cadrage
d'une page (contexte, objectif, périmètre dedans/dehors, parties prenantes, critères de succès,
hypothèses, risques majeurs). Puis liste séparément les 15 questions ouvertes qui, sans réponse,
rendraient le cadrage fragile. Marque [À CONFIRMER] tout ce qui n'est pas dans mes notes.
Notes : [notes]

P2 — Stories de données (🟡)

Voici trois stories de référence de mon équipe : [exemples] et notre Definition of Done : [DoD].
Transforme ce besoin en stories INVEST verticales (max 6). Pour chaque story : énoncé, grain de la
donnée, règle de gestion, critères d'acceptation vérifiables par requête, dépendances.
Signale toute story qui te paraît trop grosse. Besoin : [texte]

P3 — Pre-mortem (🟡)

Nous sommes dans 6 mois ; le projet suivant a échoué : [description]. Rédige les 12 causes d'échec
les plus probables, classées (organisation, données, technique, conformité, adoption). Pour chacune :
signal précoce observable et première action de prévention. Ne sois pas aimable : sois réaliste.

P4 — Compte rendu fidèle (🟢)

Voici la transcription d'une réunion. Produis : décisions (avec la phrase source entre guillemets),
actions (responsable, échéance, ou [À PRÉCISER]), points ouverts, désaccords exprimés.
N'inclus aucune décision qui n'a pas été formulée comme telle. Transcription : [texte]

P5 — Contre-lecture adverse (🔴)

Joue le rôle d'un directeur financier sceptique. Lis ce plan et formule les 10 objections les plus
dures (valeur, coût, délai, dépendances, hypothèses non étayées). Pour chacune, indique ce qui
la lèverait. Plan : [texte]

P6 — Requêtes de contrôle (🟡)

Voici le schéma (DDL sans données) : [DDL] et la règle de gestion : [règle]. Écris les requêtes
T-SQL de contrôle : unicité de la clé, orphelins référentiels, rapprochement des totaux avec la
source, détection de doublons. Chaque requête en lecture seule, avec WITH (NOLOCK), commentée,
et le résultat attendu si tout va bien.

P7 — Analyse de rétrospectives (🟡)

Voici les comptes rendus anonymisés de 6 rétrospectives : [textes]. Identifie les thèmes récurrents,
les actions promises jamais closes, et ce qui s'est amélioré. Distingue faits cités et interprétations.
Ne nomme aucune personne.

P8 — Lecture d'un tableau de bord (🟡)

Voici l'export des indicateurs de flux de 8 sprints : [CSV]. Décris les tendances, propose trois
hypothèses d'explication pour chaque anomalie en indiquant les données qui permettraient de les
départager. N'affirme aucune cause.

P9 — Dictionnaire de données (🟡)

À partir de ce schéma [DDL], rédige le dictionnaire de données : pour chaque table et colonne, une
description fonctionnelle. Lorsque l'intention n'est pas déductible du nom ou du type, écris
« À VALIDER PAR LE MÉTIER » au lieu de deviner.

P10 — Revue d'un script avant déploiement (🔴)

Relis ce script T-SQL d'alimentation comme un relecteur critique : idempotence (rejeu), gestion des
NULL, transactions, verrous, comportement si le script s'interrompt à mi-chemin, effets sur
l'historique. Liste les défauts par gravité avec le correctif proposé. Script : [code]

8. Ce qui reste humain#

L'IA est une aide de production et de contradiction. Elle ne remplace pas :

9. Mesurer le gain réel#

🟡 Pratique — mesurer localement#

Sans mesure, le gain est une impression. Un dispositif léger suffit :

1. Choisir 2 ou 3 usages (comptes rendus, stories, requêtes de contrôle) et définir pour chacun une mesure : temps de rédaction, nombre de défauts relevés à la revue, retours du métier.
2. Comparer avant/après sur 4 à 6 semaines, avec l'honnêteté d'inclure le temps de relecture : un texte généré en 1 minute et relu en 10 n'est pas gratuit.
3. Compter les erreurs interceptées par la relecture (décisions inventées, requêtes fausses) : elles justifient la règle de validation.
4. Interroger l'équipe : qualité perçue, confiance, charge cognitive.

🔴 Expert — éviter les illusions de productivité#

• Biais d'auto-évaluation : on se sent plus rapide qu'on ne l'est ; mesurer des durées, pas des impressions.
• Transfert de charge : le temps gagné à l'écriture peut migrer vers la relecture et la correction, souvent chez les seniors. Mesurer la charge de revue.
• Qualité différée : un gain de vitesse qui augmente les défauts en production n'est pas un gain. Suivre les défauts échappés et le taux de reprise (voir CI/CD, métriques de stabilité).
• Loi de Goodhart : ne pas fixer d'objectif d'« usage de l'IA » (nombre de prompts) : on obtiendra de l'usage, pas de la valeur.

Pour les indicateurs, voir Métriques et reporting de projet et le thème amélioration continue de la matrice projet informatique.

10. Pièges liés à une IA mal cadrée#

11. Voir aussi#

• Le versant outils : IA et outils et la synthèse transverse IA.
• Les méthodes : Fondamentaux, Scrum en pratique, Scrum et data, Choisir et hybrider.
• La chaîne de livraison : CI/CD, CI/CD pour la data.
• La synthèse des erreurs à éviter : Pièges et bonnes pratiques.
• Les matrices de maturité : conduite de projet informatique, conduite de projet data.
• Reporting et IA côté Power BI : IA et reporting OneLake, IA et reporting SQL Server.
• Vocabulaire : GLOSSAIRE ; notation : NOTATION.

✻ Rédigé par Claude Sonnet 5.5