Appliquer Scrum tel quel sur une mission IA, c’est préparer un crash prévisible. Les équipes découvrent trop tard que l’incertitude scientifique n’a absolument rien à voir avec l’incertitude projet classique. Un algorithme peut être techniquement juste et commercialement inutile. Une donnée peut être présente mais inexploitable ou de mauvaise qualité. Une performance de modèle peut plafonnant sans raison visible, bloquée par des contraintes non anticipées. Les sprints de deux semaines deviennent contre-productifs quand on travaille sur des expérimentations longues et multi-semaines, sur des cycles de données qui s’étalent sur un mois complet, sur des validations utilisateur qui reposent sur des prototypes jetalbles nécessitant plusieurs itérations. Le Product Owner traditionnel, habitué à traduire des demandes métier en user stories, se retrouve bloqué face à des questions purement scientifiques et techniques : « Ce réseau de neurones convergera-t-il sur ces données bruitées ? » ou « Est-ce un overfitting ou une vraie limite ? » ne sont pas des user stories. DécisionIA préconise une adaptation progressive et pragmatique d’Agile aux réalités concrètes de l’IA : sprints multi-rythmes, rôles élargis, cérémonies souples mais disciplinées. Cette hybridation éloigne du dogme Scrum puritain, certes, mais rapproche du succès réel et de la livraison tangible. Les équipes qui ont navigé cette transition gagnent six à neuf mois d’efficacité et de sérénité. Les autres bricolent dans un flou méthodologique pendant des années.
Pourquoi Scrum strict casse sur l’IA
Le problème fondamental réside dans la nature de l’incertitude. En Scrum classique, une user story mal comprise se découvre rapidement en démo. Le client dit non, on ajuste, on repart. L’itération est rapide. Sur l’IA, l’incertitude est différente : elle est scientifique et technique. L’équipe construit une solution techniquement irréprochable qui ne résout pas le besoin métier. Ou elle résout un besoin fantôme. Ou elle résout le besoin réel mais à un coût computationnel inacceptable pour les budgets opérationnels. Ces découvertes arrivent souvent à la fin du second mois, pas à la fin de la première semaine.
Les sprints courts deviennent des exercices administratifs : peu de substance scientifique boucle en deux semaines. L’équipe trace une story « Explorer l’influence de telle variable sur la performance », lance des expérimentations le lundi, et il est mercredi quand les premiers résultats arrivent. Le vendredi, elle doit présenter une démo. On fonce donc un POC bancal plutôt que d’attendre un résultat solide. La méthodologie agile devient un carcan. Les rituels du Scrum — stand-up quotidien, planning rigide, démo — sont pensés pour des équipes qui livrent du code incrémental. Sur une mission IA, beaucoup de travail n’est pas livrable chaque semaine : c’est de l’exploration, de l’expérimentation, de la validation rigoureuse. L’équipe produit peu de code visible, beaucoup de notebooks jetables, des fichiers de logs complexes, des matrices de confusion, des analyses de sensibilité.
Comment évaluer un sprint quand il n’y a rien à déployer mais que la science a progressé ? La velocity métrique classique de Scrum perd tout sens : on ne peut pas compter les story points si la majorité du travail est invisible ou incomplet. Un cadrage clair du projet est donc impératif avant de lancer tout framework agile : cela permet de définir des jalons scientifiques réalistes et d’alignement initial du comité de direction.
DécisionIA a observé des équipes entières bloquées par cette contradiction : leur directeur exigeait un reporting Scrum strict, leurs data scientists avaient besoin d’explorer sans deadline hebdomadaire. La frustration mutuelle augmentait jusqu’au point de rupture. Sans une adaptation consciente et explicite de l’agilité, le Scrum devient un obstacle au succès plutôt qu’un accélérateur. Il ralentit les projets, crée de la pression contreproductive, et tue l’initiative scientifique au nom de la méthodologie administrative.
Adapter les sprints : données, modèle, produit
Une première adaptation consiste à distinguer trois types de sprints avec cadences différentes : data sprints, model sprints et product sprints. Les data sprints durent trois à quatre semaines et visent l’audit complet d’une source de données, la définition d’un schéma d’extraction robuste, la mise en place d’une pipeline stable et testée. Un data sprint contient des expérimentations scienti scolastiques : essayer trois modes de nettoyage, en mesurer l’impact sur la distribution, choisir le meilleur selon le critère métier. Les risques de qualité doivent être documentés : taux de valeurs manquantes, détection des outliers, vérification des contraintes métier. Les model sprints durent quatre à six semaines : on expérimente l’architecture et les hyperparamètres, on valide la performance cross-validation, on teste la sensibilité aux données de test, on documente les limites. Pendant ce temps, le framework de validation s’affine constamment : métriques métier vs métriques techniques, seuils de confiance adaptés au risque, sélection des données de test représentatives. Les product sprints, eux, restent d’une ou deux semaines et visent l’intégration système : API REST ou gRPC, interface utilisateur, déploiement en staging, monitoring des performances. Cette tripartition permet à DécisionIA de sortir du mythe du sprint uniforme imposé dogmatiquement. Elle signifie aussi que certaines tâches ne se font pas en parallèle sans risque. On ne lance pas un model sprint rigoureux tant que les données ne sont pas stabilisées et documentées. On ne lance pas un product sprint tant que la performance du modèle n’a pas été validée robustement sur données holdout. Cette séquence n’est pas moins agile : elle est plus honnête et réaliste quant à la nature du travail scientifique et technique.
Rôles élargis et gouvernance scientifique
Le Product Owner IA doit combiner trois expertises : compréhension métier, littératie statistique, pragmatisme de mise en production. C’est une personne rare. Un PO classique, même brillant en extraction de besoin, sera perdu face à une question sur la performance d’un modèle. Symétriquement, un data scientist excellent sera nul pour prioriser entre trois améliorations de modèle. Le rôle du PO data s’invente : il doit traduire les résultats scientifiques en impact métier, arbitrer entre innovations scientifiques et contraintes industrielles, anticiper les fauves du déploiement. À côté, le Scrum Master IA doit comprendre l’incertitude scientifique : il ne force pas un modeste sprint data à livrer une démo si elle n’a aucun sens. Les cérémonies s’adaptent. Le stand-up n’est plus quotidien mais trois fois par semaine : moins de bruit administratif, plus de discussions sur les blocages techniques. Le planning sprint devient planning phase, sur des horizons glissants de trois à quatre semaines. La démo n’est plus devant le client ; c’est d’abord une session technique d’évaluation, puis une présentation des résultats à la gouvernance métier. Cette distinction prévient les déceptions : on ne vend pas un proto comme un produit.
Gouvernance des incertitudes et cérémonies adaptées
L’incertitude scientifique doit être explicite et anticipée dès le départ. Au lancement de chaque phase, l’équipe énumère les trois à cinq hypothèses critiques à valider. Pour chaque hypothèse, elle fixe un plan d’expérimentation clair : qu’est-ce qu’on teste, sur combien de données, avec quels critères de succès ? Cela ressemble à un protocole scientifique, parce que c’en est un. Une hypothèse validée ne ferme jamais le sujet ; elle crée une piste à explorer davantage ou une fondation pour la phase suivante. Les hypothèses invalidées ne sont pas des fracas : c’est l’IA. On apprend qu’une variable n’a pas d’impact, qu’une source de données est infofiable, qu’un algorithme populaire ne fonctionne pas ici. Cet apprentissage oriente les pivots stratégiques et accélère la convergence vers une vraie solution.
Les retrospectives et les planifications se rythment différemment selon la nature du travail. Une rétrospective mensuelle suffit pour une équipe IA en full data ou full model. Une rétrospective bi-hebdomadaire convient pour une équipe en phase product. Le planning prépare non pas deux semaines de travail ferme mais deux à trois semaines de jalons scientifiques. La démo interne, avant la démo client, permet à l’équipe d’évaluer ce qui a vraiment d’importance et de de corriger avant présentation aux sponsors. Le backlog n’est plus une liste exhaustive d’exigences mais un ensemble de questions : « Peut-on augmenter la performance sans ajouter des données ? » « Quel algorithme convergera le plus vite ? » Les réponses alimentent les expérimentations de manière itérative.
Les meetings de gouvernance et les post-mortems intègrent cette réalité scientifique : on discute des hypothèses confirmées ou infirmées, pas seulement des user stories fermées. Les équipes matures posent aussi des cadres de diagnostic en amont, définissant le périmètre, les données accessibles, la vision d’industrialisation. Cela prévient les dérapages et crée l’alignement. Cette approche hybride, entre Agile flexible et discipline scientifique, est l’avenir des missions IA structurées. DécisionIA la recommande comme fondation de tout projet data ou IA d’envergure.