Agile et intelligence artificielle : pourquoi les méthodes classiques échouent dans l’automatisation

Pourquoi Scrum et Kanban échouent dans les projets d’IA

Scrum a été inventé pour le développement logiciel.

L’IA obéit à d’autres règles.

Ignorer cela, c’est l’erreur que je vois le plus souvent chez mes clients.

Le problème des sprints : l’IA n’avance pas de façon linéaire

Un sprint dure 2 semaines.

Un modèle de machine learning peut mettre 3 semaines avant de fournir des résultats exploitables.

Tu fais quoi la semaine 1 et 2 ? Tu présentes « on est encore en phase d’entraînement » comme résultat de sprint ?

Vécu personnel.

Une équipe de devs a “rien” montré pendant 6 sprints – alors qu’ils bossaient super bien.

Le souci ? Le développement IA a des cycles de temps différents.

Parfois, la préparation des données prend 4 semaines – puis le premier modèle fonctionne du premier coup.

Parfois, tu testes 50 approches avant de trouver celle qui marche.

Impossible de tout faire rentrer dans des cycles de 2 semaines.

Chaos dans le backlog : quand les algorithmes changent les priorités

Un Product Backlog marche bien pour des features.

En IA, c’est la découverte qui fait l’ordre des priorités.

Cas vécu :

On voulait développer un outil d’analyse de sentiments sur des feedbacks clients.

On avait prévu 5 fonctionnalités :

1. Classification positif/négatif
2. Reconnaissance des émotions
3. Extraction de thèmes
4. Analyse de tendances
5. Dashboard

Après la première exploration de données : 60% des données inutilisables.

D’un coup, nettoyage des données = priorité n°1.

Ce nétait écrit nulle part dans le backlog.

Dans un projet IA, souvent ce sont les données qui décident de l’étape suivante – pas le Product Owner.

Dailies qui deviennent des weeklies (et c’est très bien comme ça)

« Qu’as-tu fait hier ? »

« Optimisé les hyperparamètres. »

« Et aujourd’hui ? »

« Optimisé les hyperparamètres. »

« Un point de blocage ? »

« L’entraînement tourne encore pour 12h. »

Voilà à quoi ressemblent les daily standups d’une équipe IA.

Inutile.

Sur un projet IA, les boucles de feedback sont plus longues.

Parfois, entraîner un modèle prend plusieurs jours.

Analyser les résultats d’un test A/B demande de la significativité statistique – souvent, c’est plusieurs semaines.

Synchroniser tous les jours, ça n’a pas de sens quand rien ne change fondamentalement au quotidien.

Les trois différences fondamentales entre le développement logiciel et l’IA

Développer un logiciel : tu sais ce que tu construis.

Développer une IA : tu sais ce que tu testes.

C’est ça, la clé.

Imprévisibilité vs planification

Avec du code, tu écris, ça marche (ou pas).

En IA, tu entraînes un modèle, ça marche à 73% – et tu ignores pourquoi.

Pas à cause de mauvais code.

Mais à cause des données ou des bizarreries du modèle.

Impossible de planifier le moment où un modèle atteint le niveau voulu de précision.

Tu ne peux qu’expérimenter et itérer.

C’est pour ça que le planning classique foire.

Un processus expérimental, pas linéaire

Le développement logiciel suit un schéma linéaire :

Besoins → Design → Implémentation → Tests → Déploiement

Le développement IA ? Un cycle d’expériences :

Hypothèse → Expérience → Évaluation → Apprentissage → Nouvelle hypothèse

80% de mon temps sur les projets IA : des expériences qui ne donnent rien.

C’est normal.

Et c’est même souhaitable.

Chaque essai infructueux rapproche de la solution.

En logiciel, 80% de code jeté, ce serait inacceptable.

En IA, c’est le chemin vers la réussite.

Qualité des données : facteur de succès numéro un

Le logiciel fonctionne avec des données de test synthétiques.

L’IA dépend de données réelles et de haute qualité.

J’ai vu des projets où l’équipe produisait du code parfait pendant 6 mois…

…le modèle restait inutile.

En cause : des données médiocres.

Dans un projet IA, 60 à 80% du temps part dans la gestion des données :

• Collecte de données
• Nettoyage des données
• Labellisation
• Validation
• Construction des pipelines

Ça ne figure pas dans un sprint logiciel classique.

Mais sans ça, aucune IA ne fonctionne.

Modes de travail AI-first : Ce qui vient après Scrum

Depuis 3 ans, j’expérimente différents modèles pour les équipes IA.

Voici ceux qui produisent vraiment des résultats.

Hypothesis-driven Development au lieu des User Stories

Oublie les User Stories.

« En tant qu’utilisateur, je veux… » ne marche pas pour l’IA.

On passe à l’Hypothesis-driven Development.

Chaque phase commence par une hypothèse mesurable :

« Si on ajoute la fonctionnalité X, la précision du modèle s’améliore d’au moins 5%. »

Ou :

« Si on utilise l’algorithme Y, le temps d’entraînement sera réduit de 50%. »

Chaque hypothèse comprend :

• Une métrique mesurable
• Un objectif quantifié
• Une estimation du temps pour l’expérience
• Des critères de succès/échec

Ça transforme « On optimise le modèle » en expérience concrète avec résultat clair.

L’expérimentation continue comme cœur du processus

En logiciel, tu développes des fonctionnalités.

En IA, tu développes des expériences.

Le process numéro un, ce n’est pas le sprint planning – c’est le design expérimental.

Notre workflow type d’expérience :

1. Définition de l’hypothèse (1 jour)
2. Mise en place de l’expérience (2-3 jours)
3. Exécution (variable : 1 jour à 2 semaines)
4. Évaluation (1-2 jours)
5. Décision (Poursuivre/Abandon/Pivot)

Important : tout est documenté.

Y compris les échecs.

Surtout les échecs.

On tient un « journal d’expériences » avec :

• Hypothèse
• Démarche
• Résultat
• Enseignements
• Étapes suivantes

C’est la ressource la plus utile pour l’équipe.

Des workflows centrés données pour les équipes IA

Les équipes logicielles s’organisent autour des fonctionnalités.

Une équipe IA doit s’organiser autour de la data.

Notre process ne passe pas par un Kanban board, mais par une data pipeline :

Chaque étape a ses critères clairs de passation.

Pas de « terminé » sans qualité mesurable.

Pratiques concrètes pour les équipes boostées à l’IA sur le terrain

Assez de théorie.

Voici les méthodes que j’utilise au quotidien.

La méthode en 3 phases pour gérer un projet IA

Je découpe chaque projet IA en 3 phases :

Phase 1 : Découverte (25% du temps)

Objectif : Comprendre ce qui est possible.

Activités :

• Exploration de données
• Proof of Concept
• Faisabilité
• Premiers modèles de base

Métrique de succès : Le problème est-il solvable par l’IA ?

Phase 2 : Développement (60% du temps)

Objectif : Construire le meilleur modèle.

Activités :

• Amélioration itérative du modèle
• Feature Engineering
• Optimisation d’hyperparamètres
• Validation croisée

Métrique de succès : Précision cible atteinte.

Phase 3 : Déploiement (15% du temps)

Objectif : Mettre le modèle en production.

Activités :

• Packaging du modèle
• Développement d’API
• Mise en place du monitoring
• A/B Testing

Métrique de succès : Modèle opérationnel en production.

Important : Les phases ne sont pas linéaires.

Tu passes de la découverte au développement, puis retour – c’est le jeu.

C’est tout à fait normal.

Agile Data Science : les sprints revisités

On parle encore de « sprints » – mais différemment.

Nos sprints IA durent 3-4 semaines (pas 2).

Chaque sprint a un objectif d’expérimentation, pas un objectif de feature.

Comment on planifie un sprint :

1. Revue des expériences : Qu’a-t-on appris aux sprints précédents ?
2. Priorisation des hypothèses : Quels tests ont le plus de potentiel ?
3. Allocation des ressources : Qui travaille sur quoi ?
4. Critères de succès : Comment on mesure le résultat ?

Le sprint review ne montre pas des features, mais des apprentissages :

• Quelles hypothèses ont été validées/infirmées ?
• Quelles découvertes ?
• Comment la performance du modèle a évolué ?
• Quels sont les prochaines expériences logiques ?

Bien organiser une équipe IA pluridisciplinaire

Une équipe IA n’a pas les mêmes rôles qu’une équipe logiciel.

Notre composition standard :

Important : Le Product Manager n’est PAS le Scrum Master.

Il définit les cibles business, pas les objectifs de sprint.

La priorisation des expériences, c’est le travail de toute l’équipe.

Stacks d’outils et processus : Ce qui marche vraiment

Les outils pour une équipe IA ne sont pas les mêmes qu’en logiciel pur.

Voilà notre stack éprouvé.

Outils de gestion de projet pour équipes IA

Jira est adapté pour le logiciel.

Pour l’IA, on combine plusieurs outils :

Suivi d’expériences : MLflow

• Toutes les expériences sont loggées automatiquement
• Paramètres, métriques, artefacts affichés au même endroit
• Comparaison de différentes versions de modèles

Gestion des tâches : Notion

• Backlog des hypothèses
• Documentation des expériences
• Partage de connaissances d’équipe
• Dashboards de qualité des données

Communication : Slack + Rapports data quotidiens

• Rapports automatisés sur la performance des modèles
• Alertes sur incidents de qualité de données
• Un canal par expérience en cours

Mais l’outil-clé, c’est le journal partagé des expériences.

On documente CHAQUE expérience – qu’elle réussisse ou non.

Versionning des modèles et des données

Le code, tu le versionnes avec Git.

Mais pour les modèles et la data ?

Notre méthode :

Data Versioning : DVC (Data Version Control)

• Chaque dataset a son numéro de version
• Data pipelines reproductibles
• Traçabilité automatique des données

Model Versioning : MLflow Model Registry

• Chaque modèle est versionné automatiquement
• Environments Staging / Production
• Rollback si régression de la performance

Versionning du code : Git + Pre-commit hooks

• Contrôle qualité automatisé du code
• Les métadonnées des expériences sont automatiquement committées
• Nettoyage automatique des Jupyter Notebooks avant commit

Sans versionning, le développement IA n’est pas reproductible.

Et si ce n’est pas reproductible, ce n’est pas débogable.

Tests et déploiement dans un environement IA

Les tests unitaires pour de l’IA, c’est autre chose que pour du dev classique.

Tu ne testes pas que des fonctions : tu contrôles aussi la qualité des données et la performance du modèle.

Notre framework de tests :

Tests sur la qualité des données

• Validation du schéma (toutes les colonnes sont-elles présentes ?)
• Vérification de la fraîcheur des données
• Tests statistiques (la distribution a-t-elle bougé ?)
• Contrôle du taux de valeurs manquantes

Tests sur la performance du modèle

• Seuils de précision à respecter
• Tests sur la latence
• Tests sur la consommation mémoire
• Détection de biais

Tests d’intégration

• Tests bout en bout de la pipeline
• Tests de réactivité de l’API
• Tests de charge

Le déploiement passe par du blue-green deployment avec rollback auto.

Si la performance du modèle chute de plus de 5%, on repasse automatiquement à la version précédente.

Erreurs fréquentes lors de la transition vers des modes de travail assistés par l’IA

J’ai vu passer les mêmes écueils chez presque tous les clients.

Voici les plus courants – et comment les éviter.

Le Scrum Master qui se transforme en Product Owner IA

Erreur classique :

L’entreprise veut garder son agilité et nomme le Scrum Master Product Owner IA.

Problème : Un Scrum Master sait gérer les process, mais la data science, il ne connaît souvent pas.

Impossible pour lui de prioriser les expériences ; il ne sait pas ce qui est réaliste.

La solution : Le Product Owner IA doit avoir un profil technique.

Il doit comprendre :

• Comment fonctionne le Machine Learning
• Ce qu’implique la qualité des données
• Le temps nécessaire à l’entraînement d’un modèle
• Quelles métriques sont pertinentes

Chez nous, le Product Owner IA est toujours un Data Scientist ou ML Engineer avec sens business.

Jamais un simple gestionnaire de projet.

Pourquoi la définition de Done classique ne marche pas

Logiciel : « La feature fonctionne selon le cahier des charges » = Done.

IA : « Le modèle atteint 85% de précision » = Done.

Mais si le modèle ne fait que 84% ?

Ce nest pas fini ?

La définition classique aboutit à un cycle sans fin d’optimisations.

Notre approche : définition probabiliste du Done.

Au lieu de « le modèle doit faire 85% », on formalise :

« Le modèle fait au moins 80% de précision et fait mieux que l’ancien benchmark. »

Et on pose une limite dans le temps :

« Si après 4 semaines d’optimisations il n’y a pas d’amélioration significative, le modèle actuel passe en production. »

Ça évite le piège du perfectionnisme et permet d’améliorer en prod, itérativement.

Change management pour équipes « classiques »

La difficulté n’est pas technique.

C’est le changement humain.

Les développeurs ont l’habitude de systèmes déterministes.

L’IA fonctionne avec de la probabilité.

Il faut changer d’état d’esprit.

À chaque transition, j’applique :

1. Gestion des attentes

• Communication ouverte : 80% des expériences échouent
• C’est normal et utile
• Le succès se mesure différemment

2. Pair programming version IA

• Des Data Scientists expérimentés avec des développeurs « classiques »
• Transfert de connaissances via les code reviews
• Expérimentations planifiées à deux

3. Apprentissage continu

• « ML Learning Sessions » toutes les semaines
• Études de cas d’expériences réussies
• Post-mortems sur les essais ratés

La transition prend 3 à 6 mois.

Intègre-le à ta roadmap.

Et célèbre les petites victoires – même les expérimentations « ratées » apportant des infos précieuses.

Questions fréquentes

Combien de temps prend la transition de Scrum vers des modes de travail orientés IA ?

D’après mon expérience, la transition prend 3 à 6 mois. L’équipe doit adopter de nouveaux réflexes et installer les nouveaux process. L’important : progresser étape par étape, sans tout bouleverser d’un seul coup.

Est-ce qu’on ne peut vraiment pas mixer Scrum et développement IA ?

Si, mais il faut adapter Scrum. Sprints rallongés (3-4 semaines), des objectifs axés expérimentation et non fonctionnalité, et plus de souplesse au niveau du temps. Du Scrum pur et dur ne marche pas sur un projet IA.

Quelles sont les rôles-clés dans une équipe IA ?

Au minimum : Data Scientist, Data Engineer, ML Engineer. Sur une petite équipe, une personne peut porter plusieurs casquettes, mais tous ces domaines doivent être couverts. Un Product Manager qui connaît l’IA, c’est aussi indispensable.

Comment mesurer le succès des expériences IA ?

Avec des métriques définies à l’avance : accuracy, precision, recall ou des KPIs business. Attention : même les expériences qui échouent sont utiles dès lors qu’elles apportent des apprentissages. Tout est documenté, systématiquement.

Quels sont les plus gros défis de la transition ?

Le change management est plus dur que la technique. L’équipe doit apprendre à fonctionner dans l’incertitude et à raisonner en probabilités, pas en mode tout-ou-rien. Il faut aussi de nouveaux outils et de vraies stratégies de versioning pour données et modèles.

Quels outils sont essentiels pour une équipe IA ?

MLflow pour le suivi des expériences, DVC pour le versionning des données, un cloud provider pour la puissance de calcul, et un outil de doc type Notion. Git seul ne suffit pas – il faut des outils pensés pour la data science.

Comment gérez-vous l’imprévisibilité des projets IA ?

Avec des expérimentations « timeboxed » et des critères Go/No-Go clairs. On se fixe des limites de temps pour les phases d’optimisation, on définit des minima de performance, et on garde de la marge dans les plannings. La transparence sur les incertitudes avec les parties prenantes est vitale.

Les outils de gestion de projet classiques suffisent-ils pour une équipe IA ?

Pas entièrement. Jira peut servir pour le pilotage des tâches simples, mais il faut des outils complémentaires pour l’historisation des expériences et la traçabilité de la data. On préfère combiner divers outils spécialisés.

Comment organiser les code reviews pour du code ML ?

La revue de code ML ne se limite pas à la qualité du code : on regarde aussi la pertinence de l’expérience, la propreté/distribution des données et la validation des modèles. Le pair programming entre experts data et devs logiciels facilite le transfert de compétences.

Que faire si un projet IA échoue complètement ?

Ça arrive dans 15-20% des cas, c’est tout à fait normal. L’important est de s’en rendre compte tôt et de pivoter vite. Documente toutes les leçons – elles sont précieuses pour les projets futurs. Un projet « raté » peut éviter beaucoup d’erreurs à d’autres.