

- Description
- Machine mécanique à prédire les marées, faite de poulies, de câbles et de cadrans en laiton.
- Source
- Steven Fine · page d’origine
- Licence
- CC0 Domaine public
L'IA dans les outils de planification et de gestion de versions
Vous saurez où l'IA apporte réellement dans les outils de suivi (rédaction et découpage de stories, résumés, déduplication, estimation, détection de risque) et dans la gestion de versions…
En bref
- Vous saurez où l'IA apporte réellement dans les outils de suivi (rédaction et découpage de stories, résumés, déduplication, estimation, détection de risque) et dans la gestion de versions (revue de code, messages de commit, résolution de conflits).
- Vous disposerez d'un tableau gain / risque / maturité /5 par cas d'usage.
- Vous saurez poser des garde-fous (confidentialité, hallucinations, responsabilité, dette cachée) et rédiger des prompts utiles.
- Les fonctions IA évoluent très vite : tout élément daté « état 2026-10 » est à revérifier avant décision.
Contexte : équipe de 5 à 15 personnes, projet data/BI (datamart SQL Server, rapports Power BI, TFVC/Azure DevOps Server). Notes /5 = appréciations contextuelles (NOTATION). Pour la conduite de projet en général, voir IA en conduite de projet ; pour la synthèse transverse, IA, synthèse.
Sur cette page
- 🟢 Novice — Ce que « IA » veut dire ici
- 🟢 Novice — Où trouver l'IA aujourd'hui (état 2026-10)
- 🟡 Pratique — Cas d'usage dans les outils de planification
- 🟡 Pratique — IA et gestion de versions
- 🔴 Expert — Tableau de synthèse gain / risque / maturité
- 🔴 Expert — Garde-fous
- 🔴 Expert — Ce que l'IA ne remplace pas
- Voir aussi
Niveau : 🟢→🔴
🟢 Novice — Ce que « IA » veut dire ici#
Dans les outils de planification, « IA » désigne presque toujours un modèle de langage (LLM) branché sur les données de l'outil (tickets, commentaires, wiki, code). Il sait reformuler, résumer, classer, proposer un brouillon, chercher par sens. Il ne sait ni décider, ni garantir l'exactitude, ni connaître le contexte non écrit de votre équipe. Un brouillon IA relu est un gain ; un brouillon IA non relu est une dette.
Trois degrés d'autonomie :
| Degré | Exemple | Qui décide |
|---|---|---|
| Assistant (suggère) | brouillon de description, résumé | l'humain accepte ou rejette |
| Copilote (agit sous supervision) | applique des étiquettes, propose un découpage | l'humain valide en lot |
| Agent (agit seul sur un périmètre) | prend un ticket, ouvre une demande de fusion | l'humain relit le résultat, pas le chemin |
Commencez par le degré assistant sur des textes non sensibles, mesurez la qualité sur 20 cas réels, puis seulement élargissez.
🟢 Novice — Où trouver l'IA aujourd'hui (état 2026-10)#
| Outil | Fonctions IA (à revérifier) |
|---|---|
| GitHub Copilot | complétion, chat, revue de code sur PR, agent de codage assignable à une issue |
| Azure DevOps | intégration avec l'agent de codage de GitHub depuis un work item Azure Boards (préversion en 2025, déploiement en disponibilité générale annoncé en décembre 2025 ; dépôts GitHub requis, donc inutilisable avec TFVC) ; extensions et agents via API/MCP |
| Jira / Rovo (Atlassian) | résumés, génération de contenu, recherche, agents ; crédits Rovo inclus par utilisateur et par mois dans les offres payantes (Standard, Premium, Enterprise), au-delà facturés à l'usage selon un plafond fixé par l'administrateur |
| GitLab Duo | assistant de code, résumés de tickets/MR, explication de pipeline (selon palier) |
| Linear | triage assisté, résumés, agents assignables ; intégré aux paliers payants (à vérifier) |
| Notion, Asana, Monday… | résumés, rédaction, remplissage de champs |
| Assistants généralistes (Claude, ChatGPT, Microsoft Copilot) | tout ce qui précède, via copier/coller ou connecteurs |
Symptôme : un outil promet « l'IA gratuite » puis la consommation explose. Cause : modèles tarifés à l'usage (crédits). Remède : plafonner par politique (budget, groupe d'utilisateurs), mesurer le coût par cas d'usage, comparer au gain de temps réel.
🟡 Pratique — Cas d'usage dans les outils de planification#
Rédaction et amélioration de stories#
L'IA transforme une demande informelle (« les chiffres du secteur Nord sont faux ») en une story structurée (contexte, valeur, critères d'acceptation). Gain réel sur la forme, risque sur le fond : elle comble les trous avec des hypothèses plausibles.
Prompt type :
Tu es un analyste BI. Voici une demande brute d'un utilisateur : « {texte} ».
Contexte : datamart SQL Server, rapports Power BI, mesures en euros, calendrier fiscal décalé.
Produis : (1) une story au format « En tant que… je veux… afin de… », (2) 5 critères d'acceptation
vérifiables avec seuils chiffrés, (3) la liste des QUESTIONS à poser au demandeur avant de commencer,
(4) les hypothèses que tu as faites. N'invente aucune règle métier : marque-la comme à confirmer.
Demandez toujours les questions ouvertes et les hypothèses. Le plus grand risque n'est pas un texte faible, c'est un texte convaincant et faux.
Découpage de travail#
L'IA propose un découpage d'une epic en stories ou d'une story en tâches. Il est bon pour énumérer, mauvais pour trier par valeur et pour respecter les contraintes réelles (dépendances de sources, fenêtres de livraison). Appliquez le test INVEST à chaque proposition (voir Scrum en pratique) ; refusez les découpages « par couche » (une story pour la base, une pour le rapport) qui ne livrent pas de valeur isolément.
Résumés de tickets et de fils#
Résumer 80 commentaires en 5 lignes, changements de décision, personnes impliquées. Gain élevé, risque modéré : le résumé omet ce qui semble secondaire. À utiliser pour s'orienter, pas pour trancher ; garder le lien vers l'original.
Déduplication et recherche sémantique#
La recherche par sens trouve des tickets semblables malgré des mots différents. La déduplication est suggérée, jamais appliquée seule : deux tickets proches peuvent avoir des conditions différentes.
Estimation#
L'IA peut comparer un ticket à l'historique (« 6 tickets similaires ont pris entre 2 et 5 jours »). Elle ne remplace pas l'estimation d'équipe (le planning poker sert surtout à découvrir les écarts de compréhension). Utiliser l'IA pour fournir des références et non un chiffre.
Détection de risque et d'anomalie#
Signaler les tickets qui vieillissent, les dépendances non traitées, les sprints sur-engagés, les mots-clés d'incident. Utile en filet de sécurité, avec des seuils explicables ; les alertes opaques sont ignorées au bout d'une semaine.
Triage et classification#
Étiqueter, router, évaluer la criticité d'une demande de support. Gain fort sur gros volumes ; contrôler un échantillon hebdomadaire et suivre le taux d'erreur.
Rédaction de rapports, notes de version et comptes rendus#
À partir des tickets liés à un kit, l'IA rédige des notes de version lisibles. Vérifier les faits (numéros, dates, périmètre) : c'est de la mise en forme, pas de l'analyse.
Pour un kit livré mensuellement, on extrait par requête la liste des tickets liés aux changesets, on demande à l'IA de les classer (correctif / évolution / technique) et de rédiger des notes en deux niveaux (utilisateur / technique). Le chef d'équipe relit en 10 minutes ce qui prenait 90 minutes, mais corrige systématiquement la rubrique « impact sur les chiffres », que l'IA ne peut pas deviner.
🟡 Pratique — IA et gestion de versions#
| Cas d'usage | Détail | Limites |
|---|---|---|
| Messages de commit / de changeset | à partir du diff, proposer un message clair | décrit le quoi, rarement le pourquoi ; compléter à la main |
| Revue de code | détecte erreurs courantes, incohérences, oublis | peu de compréhension du métier ; faux positifs ; ne remplace pas la revue humaine |
| Explication de diff | résumer un gros changement pour le relecteur | peut masquer un détail critique |
| Résolution de conflits | propose une fusion | le risque est une fusion plausible mais fausse : toujours tester |
| Génération de tests | squelettes de tests, cas limites | tests tautologiques ; vérifier que les assertions testent un comportement |
| Migration TFVC → Git | aide à scripter, expliquer des commandes | ne remplace pas la validation de l'historique converti |
| Agent de codage | prend une issue, ouvre une PR | revue humaine obligatoire, périmètre limité, pas d'accès aux secrets |
SQL et BI : spécificités#
- T-SQL / DAX générés : exacts syntaxiquement, parfois faux sémantiquement (jointure qui duplique, contexte de filtre mal compris). Toujours rejouer sur un jeu de chiffres de référence.
- Revue de scripts SQL : demander explicitement de vérifier l'idempotence, les transactions, les index manquants, les
NULLdans les jointures et les conversions implicites. - Données sensibles : ne jamais coller des données clients réelles dans un service non approuvé ; anonymiser ou travailler sur le schéma seul.
Exemple de prompt de revue :
Revue du script T-SQL ci-dessous (SQL Server, niveau de compatibilité 130).
Vérifie : idempotence (rejouable sans effet de bord), gestion des erreurs, jointures qui
dupliquent des lignes, comportement avec NULL, verrous potentiels, noms d'objets qualifiés.
Réponds sous forme de tableau : ligne | problème | gravité | correctif proposé.
Ne réécris pas le script entier.
Symptôme : le code généré compile, passe la revue rapide, mais produit un total faux de 2 % sur un client. Cause : jointure un-à-plusieurs non détectée, que l'IA a jugée plausible. Remède : test de réconciliation (total avant/après, par client) systématique pour tout changement de logique SQL/DAX, quelle que soit l'origine du code.
🔴 Expert — Tableau de synthèse gain / risque / maturité#
Échelles : gain (temps ou qualité apportés), risque (conséquence d'une erreur non détectée), maturité (fiabilité actuelle de la fonction). Contexte : équipe 5–15, data/BI. Appréciations d'expert, non mesurées.
| Cas d'usage | Gain /5 | Risque /5 | Maturité /5 | Prérequis | Garde-fous |
|---|---|---|---|---|---|
| Reformuler / rédiger une story | 4 | 3 | 4 | demande claire | questions ouvertes + hypothèses obligatoires |
| Générer des critères d'acceptation | 4 | 3 | 4 | contexte métier fourni | validation PO |
| Découper epic/story | 3 | 3 | 3 | backlog structuré | test INVEST, valeur par tranche |
| Résumer un ticket / un fil | 4 | 2 | 4 | commentaires lisibles | lien vers l'original |
| Dédupliquer | 3 | 2 | 3 | base de tickets propre | confirmation humaine |
| Estimer (références historiques) | 2 | 3 | 2 | historique fiable | jamais un chiffre imposé |
| Détecter risque / retard | 3 | 2 | 3 | métriques fiables | seuils explicables |
| Trier / classer des demandes | 3 | 3 | 3 | taxonomie stable | échantillon de contrôle |
| Notes de version | 4 | 2 | 4 | tickets liés aux livraisons | relecture des chiffres |
| Message de commit | 3 | 1 | 4 | diff lisible | compléter le « pourquoi » |
| Revue de code (assistée) | 3 | 3 | 3 | conventions écrites | revue humaine maintenue |
| Résolution de conflit | 2 | 4 | 2 | tests automatiques | tests obligatoires, jamais en aveugle |
| Génération de tests | 3 | 3 | 3 | cibles de comportement | contrôle des assertions |
| T-SQL / DAX générés | 3 | 4 | 3 | jeu de référence | réconciliation chiffrée |
| Agent de codage sur ticket | 3 | 4 | 2 | CI robuste, dépôt Git | périmètre étroit, revue, pas de secrets |
| Requêtes WIQL/JQL/OData en langage naturel | 3 | 2 | 4 | schéma de champs connu | exécution sur échantillon |
Le risque n'est pas dans l'erreur visible, mais dans l'erreur plausible. Là où une erreur coûte cher (chiffres financiers, droits d'accès RLS, données personnelles), la maturité exigée est plus haute, quelle que soit la note de la fonction.
🔴 Expert — Garde-fous#
Confidentialité et conformité#
- Classer les données : ce qui peut sortir (titres de tickets génériques) et ce qui ne le peut pas (noms de clients, données personnelles, secrets, requêtes contenant des chaînes de connexion).
- Choisir le périmètre contractuel : l'outil utilise-t-il vos données pour entraîner ses modèles ? Où sont-elles traitées (région) ? Rétention ? À vérifier dans les conditions du fournisseur et à valider avec le DPO ; RGPD : base légale, information des personnes, minimisation.
- Journaliser : qui a utilisé l'IA pour produire quoi (surtout pour les agents).
Hallucinations et vérification#
| Risque | Parade |
|---|---|
| Fait inventé (une règle métier, une référence) | exiger les sources ; vérifier les chiffres, noms et références ; refuser de produire en l'absence d'information |
| Cohérence apparente, erreur de fond | tests de réconciliation, revue croisée |
| Obsolescence | ne pas se fier à la mémoire du modèle pour des versions ou tarifs récents ; vérifier la documentation officielle |
| Biais de confirmation | demander explicitement un contre-argument |
Responsabilité et compétences#
- La responsabilité reste humaine : le nom dans le changeset ou la validation de la recette engage la personne, pas l'outil.
- Dette cachée : du code ou du texte produit vite mais non compris devient un coût plus tard ; imposer « je sais expliquer ce que j'ai accepté ».
- Compétences des juniors : l'IA peut court-circuiter l'apprentissage. Prévoir des exercices sans assistance et des revues orientées « pourquoi ».
- Dépendance : conserver la capacité de travailler sans l'outil (pannes, changement de fournisseur, coûts).
Déploiement progressif#
- Cadrer : cas d'usage, données autorisées, responsable.
- Expérimenter sur un périmètre restreint, avec des critères de succès chiffrés (temps gagné, taux d'erreur, satisfaction).
- Mesurer sur 4 à 6 semaines ; comparer avec une période sans IA.
- Décider : étendre, ajuster, ou arrêter.
- Entretenir : revue trimestrielle (fonctions, coût, incidents, conformité).
Symptôme : le gain annoncé (« 30 % plus rapide ») ne se retrouve pas dans les délais. Cause : mesure de la production de texte et non du flux de bout en bout ; les relectures et corrections absorbent le gain. Remède : mesurer le lead time et les défauts échappés avant/après, pas le nombre de caractères générés. Voir 10 — Métriques.
🔴 Expert — Ce que l'IA ne remplace pas#
- Le jugement de priorité : arbitrer entre deux valeurs concurrentes engage une responsabilité de produit.
- La relation avec les parties prenantes : comprendre ce que dit (et ne dit pas) un utilisateur.
- La recette métier : décider qu'un chiffre est juste demande de connaître le métier ; voir recette et validation (matrice).
- Les décisions d'architecture : l'IA propose des options ; le compromis dépend du contexte, de la dette acceptée, de l'organisation.
- La confiance de l'équipe : une rétrospective écrite par une machine n'est pas une rétrospective.
Documenter dans le wiki une charte d'usage de l'IA : cas d'usage autorisés, interdits, règle de relecture, signature des contenus générés lorsqu'ils sont publiés. Revoir deux fois par an.
Voir aussi#
- Panorama · Azure DevOps en profondeur · Jira et alternatives · Comparatif
- IA en conduite de projet · Pièges et bonnes pratiques · IA, synthèse transverse
- GDS et données SQL/BI · Git en profondeur · Glossaire
✻ Rédigé par Claude Sonnet 5.5