L’agilité sans les bonnes pratiques de développement, est-ce possible ?

On associe souvent l’agilité à la réalisation des développements en mode itératif, à la mise en place des Daily meetings, des sprints et de temps en temps des rétros — et on considère qu’on fait de « l’agilité ».

Quid des bonnes pratiques agiles telles que l’automatisation des tests, le TDD ou le BDD ? Quid de l’automatisation des déploiements ? Quid de la qualité du code et de la dette technique ? Peut-on commencer sans vision claire sur l’ensemble de ces axes ?

Ces débats ressemblent bien souvent à une bataille des experts techniques contre les métiers, où tout le monde a ses raisons mais personne n’est d’accord. La décision de mettre en place ces bonnes pratiques arrive souvent tardivement et se fait au détriment de fonctionnalités métiers et d’autres priorités.

Mon avis est assez tranché : il faut que les bonnes pratiques de l’agilité soient mises en place rapidement, et surtout ne pas avoir peur de dégager du temps pour démarrer ce processus. Le temps est souvent l’ennemi des bonnes pratiques. Le débat doit être sérieux et éclairé, sans être très technique.

La mise en place de ces bonnes pratiques est un vrai sujet, sur lequel de nombreux projets ont failli. Les considérer comme des options « si nous avons de la capacité dans le sprint » est une très mauvaise idée, car la décision se prendra toujours au dernier moment. Leur intégration doit être faite dès le début.

Il faut également prendre le temps d’expliquer aux parties prenantes la pertinence de ces bonnes pratiques pour obtenir un système plus robuste et plus performant. Avoir une vision claire n’est pas un luxe, c’est le minimum pour réussir.

Les quatre pratiques qui font la différence

Cinq ans après la première version de cet article, la liste n’a pas changé. Ce qui a changé, c’est qu’elle est devenue mesurable, et qu’elle figure noir sur blanc dans SAFe au titre de la qualité intégrée (Built-in Quality) et du DevOps.

• Tests automatisés, avec TDD ou BDD quand l’équipe y est prête : une fonctionnalité sans test automatisé n’est pas terminée, elle est en sursis.
• Intégration continue : chaque changement intégré et vérifié plusieurs fois par jour ; une branche qui vit une semaine est déjà une dette.
• Déploiement continu : un pipeline qui amène un changement jusqu’en production sans étape manuelle — ce que SAFe appelle le Continuous Delivery Pipeline.
• Dette technique visible et priorisée : dans le backlog, estimée, arbitrée avec les Business Owners comme n’importe quelle feature, pas dans un tableur que personne n’ouvre.

Comment le dire aux parties prenantes

Pas en termes techniques. En termes de délai et de risque : combien de temps entre une demande et sa mise en production, combien de mises en production par semaine, combien d’incidents par mise en production, combien de temps pour rétablir. Ce sont les quatre indicateurs DORA, que SAFe reprend dans sa mesure du flux ; ils parlent à un directeur métier comme à un architecte, et ils bougent visiblement quand les pratiques sont en place.

Ce que les agents IA changent, et ce qu’ils ne changent pas

En 2026, une part croissante du code est écrite par des agents. Cela ne rend pas ces pratiques optionnelles : cela les rend indispensables. Un agent qui produit du code sans tests automatisés, sans intégration continue et sans revue produit de la dette plus vite qu’un humain. C’est exactement ce que montre l’atelier Autonomous Software Delivery : le harnais — tests, garde-fous, conditions d’acceptation automatisées — est ce qui rend le dispositif utilisable en production, et il n’est rien d’autre que ces bonnes pratiques poussées jusqu’au bout.

J’en conclus que l’agilité sans les bonnes pratiques de développement est une chimère — d’où le titre de cet article.