Neuf heures cinq, dans une salle de vingt mètres carrés. Six développeurs debout, un tableau de tickets projeté au mur, et la même phrase répétée six fois : « hier j’ai avancé sur le module de facturation, aujourd’hui je continue, pas de blocage ». La réunion dure onze minutes et n’apprend rien à personne. C’est le point de départ le plus fréquent des conversations que nous avons sur l’intelligence artificielle et la méthode Scrum en entreprise : un rituel devenu récitation, dans une équipe qui livre pourtant, mais sans savoir pourquoi certains sprints tiennent et d’autres non.
Le vrai problème n’est presque jamais le rituel
Scrum tient en quelques règles simples : un backlog priorisé, des itérations de durée fixe, une revue, une rétrospective. Les entreprises qui s’en plaignent ont rarement mal compris ces règles. Elles butent sur trois choses beaucoup plus terre à terre : des tickets écrits trop vaguement pour être estimés, un backlog qui gonfle plus vite qu’il ne se vide, et une vélocité qui varie du simple au double sans explication partagée.
Ces trois problèmes ont un point commun. Ils portent sur du texte et des séries de chiffres, c’est-à-dire exactement la matière que les modèles de langage traitent correctement aujourd’hui.
Ce qu’un assistant peut réellement faire sur un backlog
Commençons par le plus utile et le moins spectaculaire : la réécriture des demandes. Un ticket intitulé « revoir l’export » devient, après reformulation assistée à partir du fil de discussion et de la demande client d’origine, une user story avec un contexte, un comportement attendu et trois critères d’acceptation testables. Le Product Owner corrige en deux minutes ce qu’il aurait mis vingt minutes à rédiger. Sur un backlog de trois cents éléments, l’effet cumulé est considérable.
Vient ensuite la détection des doublons et des dépendances. Un modèle repère que le ticket 214 et le ticket 302, écrits à huit mois d’intervalle par deux personnes différentes, décrivent la même chose. Il signale aussi qu’une story embarquée dans le sprint dépend d’une évolution d’API planifiée le sprint suivant, ce qui se découvre habituellement le jeudi de la deuxième semaine. Troisième usage : la préparation de la rétrospective. Fournir à l’équipe une synthèse anonymisée des tickets rouverts, des estimations dépassées et des interruptions du sprint évite de démarrer la séance sur des impressions.
Sur l’estimation elle-même, soyons plus mesurés. Un modèle entraîné sur votre historique propose une fourchette de points pour une story, et cette proposition sert d’ancrage utile au planning poker. Elle ne remplace pas la discussion, qui reste le principal intérêt de l’exercice. Une équipe qui accepterait les points proposés sans en parler perdrait précisément ce qui fait la valeur du rituel.
Vingt-quatre personnes, trois équipes, une expérience honnête
Un éditeur de logiciels de gestion de flotte automobile, vingt-quatre salariés, trois équipes de développement, a testé ces usages pendant cinq sprints de deux semaines. Le protocole était simple : une équipe témoin sans assistant, deux équipes équipées.
Les résultats méritent d’être rapportés tels quels. Le temps de préparation du sprint est passé d’environ trois heures à un peu plus d’une heure, gain net et durable. La vélocité, elle, n’a pas bougé de façon significative, ce qui a d’abord déçu le directeur technique. En revanche, l’écart entre l’engagement de début de sprint et la livraison réelle s’est resserré, parce que les stories mal définies étaient repérées avant d’entrer dans l’itération plutôt qu’au milieu. Une équipe qui tient sa parole quatre fois sur cinq au lieu de deux fois sur cinq, cela vaut mieux qu’un chiffre de vélocité en hausse. Le même raisonnement s’applique à d’autres chantiers d’automatisation, comme le montre notre article sur les tâches manuelles que l’on peut déléguer à l’IA.
Trois dérives à surveiller de près
La première tient en un mot : inflation. Un assistant qui rédige vite produit des backlogs énormes, remplis de stories bien tournées dont personne n’a besoin. Le rôle du Product Owner devient alors de supprimer, pas d’écrire.
La deuxième concerne la rétrospective. Une synthèse générée avant la séance oriente la discussion, et une équipe fatiguée se contentera de commenter le document au lieu de dire ce qui la gêne vraiment. Notre conseil est de distribuer les données brutes, jamais les conclusions. La troisième dérive est la mesure individuelle : dès que la vélocité est déclinée par développeur, le système est détourné en quelques semaines, les estimations gonflent et les chiffres deviennent inutilisables. Nous refusons ce paramétrage, même quand une direction le demande.
Combien cela coûte et par où commencer
Les assistants intégrés aux outils de suivi de tickets se facturent aujourd’hui entre 15 et 40 euros par utilisateur et par mois, souvent en supplément d’un abonnement existant. Pour trois équipes, la dépense reste modeste au regard d’une seule journée de développement perdue.
Le calendrier raisonnable tient dans un trimestre : un sprint pour choisir l’outil et le brancher sur votre suivi, deux sprints d’usage sur une seule équipe volontaire, un point d’étape franc, puis extension si les autres équipes le réclament. Elles le réclament, ou elles ne le réclament pas. Ce signal vaut tous les indicateurs. Retenez surtout que l’intelligence artificielle et la méthode Scrum en entreprise se marient bien sur la préparation et la mémoire, mal sur la décision collective, qui doit rester entre les mains de l’équipe. MINOBIA intervient sur ce type de sujet en observant deux ou trois sprints réels avant de proposer quoi que ce soit, parce qu’une démonstration d’éditeur ne dit jamais où se perd votre temps.
Questions fréquentes
Faut-il déjà pratiquer Scrum correctement avant de s’équiper ?
Oui. Un assistant amplifie ce qui existe. Sur une organisation où les sprints sont interrompus toutes les semaines par des urgences commerciales, il ne fera qu’accélérer la production de tickets abandonnés.
Nos tickets contiennent des données clients, est-ce un problème ?
C’est un point à traiter avant tout test. Vérifiez l’hébergement, la durée de conservation et l’absence de réutilisation de vos contenus pour l’entraînement, par écrit dans le contrat.
L’outil peut-il tenir le rôle de Scrum Master ?
Non. L’essentiel de ce rôle consiste à lever des blocages politiques et à protéger l’équipe, deux missions qui supposent de connaître les gens et les rapports de force.
Et pour une équipe unique de quatre personnes ?
Le gain existe surtout sur la rédaction des stories. La détection de doublons a peu d’intérêt quand tout le monde connaît le backlog par cœur.
Comment savoir si l’expérience a réussi ?
Regardez l’écart entre ce que l’équipe s’engage à livrer et ce qu’elle livre, sprint après sprint. Un écart qui se réduit vaut mieux qu’une vélocité qui grimpe.
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
