« On a fait quarante-deux points ce sprint. » Le dirigeant hoche la tête d’un air entendu, alors qu’il n’a aucune idée de ce que représente un point, ni de ce qu’aurait signifié trente-huit. Personne autour de la table n’ose le dire. Cette scène résume assez bien le rapport qu’entretiennent beaucoup de PME avec leurs indicateurs de projet, et c’est par là qu’il faut entrer dans le sujet de l’IA pour la gestion des projets agiles en PME, plutôt que par le catalogue des outils disponibles.
La vélocité mesure une équipe, jamais une personne
Une vélocité est une unité locale. Elle vaut pour une équipe donnée, avec sa composition, son produit et sa manière d’estimer. Comparer celle de deux équipes n’a aucun sens, et l’utiliser pour évaluer un développeur en a encore moins. Nous refusons systématiquement ce type de demande quand elle nous est adressée, parce qu’elle produit toujours le même résultat : les estimations gonflent, le chiffre monte, et plus personne ne sait où en est réellement le produit.
Ce que la vélocité sert à faire est plus modeste et plus utile. Elle permet de répondre à une seule question devant un client ou un investisseur : compte tenu de notre rythme des derniers mois, à quelle date raisonnable pouvons-nous nous engager ? Rien de plus.
Pourquoi l’agilité tient mal dans une structure de trente personnes
Un éditeur de logiciel pour cabinets vétérinaires, trente-cinq personnes, nous décrivait son quotidien ainsi : trois développeurs, dont deux assurent aussi le support client, un chef de produit qui fait accessoirement de la vente, et un patron qui code encore le week-end. Aucun manuel de méthode ne décrit cette situation, qui est pourtant celle de la majorité des PME françaises.
Le problème n’est pas le manque de rituels. C’est l’interruption. Un développeur happé quatre fois par jour par un appel client ne produit pas la moitié de ce qu’il produirait sans interruption : il en produit bien moins, parce que la reprise coûte plus cher que l’interruption elle-même. Aucune méthode ne corrige cela. Seule une décision d’organisation le fait, par exemple protéger deux demi-journées par semaine où le support est assuré par une seule personne d’astreinte.
Nous le disons sans détour à nos clients : si vous ne réglez pas cette question-là, aucun outil d’assistance ne rattrapera la différence.
Estimer, le terrain où la machine apporte réellement quelque chose
L’estimation reste l’exercice le plus détesté et le plus mal fait. L’apport de l’IA pour la gestion des projets agiles en PME y est net, à condition d’avoir un historique un peu fourni. En rapprochant une demande nouvelle des demandes traitées auparavant, un modèle propose une fourchette de charge assortie de son degré d’incertitude, et surtout signale les demandes dont la formulation ressemble à celles qui, par le passé, ont systématiquement débordé.
Chez l’éditeur cité plus haut, ce rapprochement a mis en évidence un motif que personne n’avait vu : toutes les demandes touchant à l’export comptable avaient dépassé leur estimation d’au moins soixante pour cent, sur deux ans. La cause était un module ancien que tout le monde évitait de regarder. Le sujet a été traité une fois pour toutes, et les estimations sur ce périmètre sont redevenues fiables. La question du coût réel d’un module, sujet voisin, se traite avec les méthodes évoquées dans notre article sur l’analyse des coûts par l’intelligence artificielle.
Voir ce qui coince avant la rétrospective
Une rétrospective arrive après. C’est sa nature, et c’est sa limite. Les signaux d’un sprint qui part de travers existent pourtant dès le troisième jour : une tâche qui n’a pas bougé de colonne, un ticket rouvert deux fois, une demande dont la description a changé trois fois depuis le lancement, un travail terminé mais qui attend une relecture depuis quatre jours.
Ces signaux se surveillent automatiquement, et une alerte discrète adressée au chef de produit vaut mieux qu’un constat en fin de cycle. Deux conditions pour que cela fonctionne : l’alerte porte sur un flux de travail, jamais sur une personne, et elle reste rare. Un tableau de bord qui clignote en permanence est ignoré au bout de trois semaines, nous l’avons vu se produire plus d’une fois.
Les usages qui abîment plus qu’ils n’apportent
- Le classement des développeurs par volume produit, qui détruit l’entraide en quelques semaines.
- La génération automatique de comptes rendus que personne ne relit et que tout le monde cesse de lire.
- La prévision de date présentée au client comme une certitude alors qu’elle sort d’une fourchette.
- L’écriture massive de code non relu, qui gonfle la vélocité affichée et la dette technique en même temps.
- L’ajout d’un outil supplémentaire dans une équipe qui en utilise déjà six sans les maîtriser.
Ce dernier point revient plus souvent qu’on ne l’imagine. La question à se poser avant d’ajouter quoi que ce soit est de savoir ce que l’on retire en échange.
Quatre à six mois pour installer un rythme
Un cycle court, deux semaines dans la plupart des cas, ne devient exploitable qu’après huit à dix itérations. Avant, les données d’historique sont trop maigres pour qu’une assistance à l’estimation produise autre chose qu’un chiffre au hasard. Comptez donc quatre à six mois entre le premier sprint et le moment où les prévisions commencent à tenir. Ce délai n’est pas un défaut de la méthode, c’est le temps qu’il faut à une équipe pour apprendre à s’estimer elle-même.
Employée avec discernement, l’IA pour la gestion des projets agiles en PME ne fait pas aller les équipes plus vite. Elle rend visible ce qui les ralentit, et elle épargne au chef de produit une bonne partie du travail de compilation qui l’éloigne de son produit. Si vous voulez savoir ce que votre historique de projets contient déjà comme enseignements, MINOBIA peut le regarder avec vous avant que vous n’achetiez quoi que ce soit.
Questions fréquentes
Peut-on comparer la vélocité de deux équipes ?
Non, et la tentative se retourne toujours contre celui qui la lance. Les points sont une monnaie locale, sans taux de change.
Faut-il un historique important pour que l’estimation assistée fonctionne ?
Quelques centaines de demandes traitées suffisent pour obtenir des fourchettes crédibles. En dessous, l’outil reproduit surtout le bruit de vos anciennes approximations.
Une PME de dix personnes a-t-elle besoin de tout cela ?
Rarement. À cette taille, une conversation quotidienne de dix minutes remplace la plupart des indicateurs. Le sujet devient pertinent quand plusieurs équipes se coordonnent.
Comment éviter que les estimations soient gonflées ?
En cessant d’utiliser la vélocité comme critère d’évaluation individuelle. Dès qu’un chiffre sert à noter quelqu’un, il cesse de mesurer quoi que ce soit.
Que vaut le code produit par un assistant génératif ?
Il fait gagner du temps sur le travail répétitif et en fait perdre sur ce qui touche au cœur métier. La relecture par un développeur expérimenté reste non négociable.
Prêt à concrétiser votre projet IA ?
À propos de l’auteur
Joël Obitz est entrepreneur et fondateur de MINOBIA, cabinet spécialisé dans l’intégration stratégique de l’intelligence artificielle au sein des PME et ETI. Fort de 20 ans d’expérience dans le B2B industriel, il accompagne les entreprises dans leur transformation numérique, avec une approche directe, pragmatique et orientée résultats.
Contactez-nous : contact@minobia.ai
Suivez-nous sur LinkedIn et Facebook
MINOBIA – Activateur France Num https://www.francenum.gouv.fr/activateurs/minobia
