Pourquoi les transformations « agiles » échouentsans la livraison continue

0,5 % des projets de grande envergure respectent le budget, les délais et la valeur attendue. Les 99,5 % restants ne sont pas des accidents. Ce sont les conséquences structurelles d’un modèle de tarification et de gestion de projet dont les limites sont documentées depuis des décennies.

0,5 %

des projets sont livrés dans les temps, dans le budget et avec la valeur prévue

Flyvbjerg, How Big Things Get Done, 2023 (16 000 projets)

52,1 %

des projets dépassent leur budget initial

Flyvbjerg, How Big Things Get Done, 2023 (16 000 projets)

2/3

des fonctionnalités développées n’apportent aucune valeur mesurable

Kohavi et al., Microsoft Research, 2009

Quand le périmètre, le budget et les délais sont fixés en même temps (triangle de fer), le projet n’a aucune marge d’adaptation. La pression monte jusqu’à ce que quelque chose cède : le périmètre réel (des fonctionnalités disparaissent en silence), la qualité du code (les raccourcis s’accumulent), ou le budget (avenants, refinancements, deuxième contrat pour terminer ce que le premier aurait dû livrer).

Les story points illustrent bien ce mécanisme. À l’origine, les équipes Extreme Programming estimaient en « jours idéaux », une abstraction du temps de travail sans interruption. Les clients lisaient « 3 jours idéaux » et comprenaient « mercredi ». Ils s’engageaient auprès de leur hiérarchie sur cette base, et les équipes se retrouvaient tenues à des délais qu’elles n’avaient jamais donnés. Les story points ont été créés pour rompre ce lien avec le calendrier : une unité volontairement abstraite, sans conversion possible en jours.

L’industrie a rétabli la conversion. Les story points ont été multipliés par un coefficient arbitraire pour obtenir des jours, puis des dates, puis des engagements contractuels. En 2019, Ron Jeffries, l’un des créateurs des story points, a écrit : « I may have invented story points, and if I did, I’m sorry now. » Le backlog de sprint, lui, n’est rien d’autre qu’un diagramme de Gantt pivoté de 90 degrés (Frédéric Leguedois).

Des milliards de fonds publics gaspillés sur des projets informatiques, documentés par les cours des comptes et les parlements de plusieurs pays.

400 M€

pour un système RH destiné à 1,1 million d’agents. Le projet a été abandonné après 11 ans, n’ayant couvert que 2 % des agents concernés.

Cour des comptes, 2020

5,1 Mds CAD

pour un système de paie destiné à 300 000 fonctionnaires, toujours incapable de les payer correctement après plus de 10 ans de développement. Budget initial : 310 millions.

Vérificateur général du Canada, 2026

10 Mds GBP

pour numériser les dossiers médicaux de 50 millions de patients, démantelé après 9 ans. Le Parlement britannique a qualifié ce programme de « l’un des pires fiascos contractuels de l’histoire du secteur public ».

House of Commons, 2013

En revanche, les organisations qui pratiquent la continuous delivery obtiennent des résultats mesurables :

182x

plus de capacité à livrer de la valeur aux clients

8x

moins de pannes en production

2 293x

plus rapide pour rétablir le service en cas de panne

DORA State of DevOps 2024

Le résultat business documenté :

+50 %

de croissance de capitalisation boursière sur 3 ans pour les organisations qui pratiquent la livraison continue

Forsgren et al., Accelerate, IT Revolution Press, 2018, Annexe B (analyse 2014 sur le sous-échantillon coté en bourse, non répliquée depuis)

« Le développement agile fonctionne parce qu’il est l’application de la méthode scientifique au développement logiciel. »

Dave Farley, Hypothesis Based Development

Chaque idée est une hypothèse. Chaque livraison est une expérience. Chaque retour utilisateur est une donnée.

Développement agile : ce que le Manifeste dit vraiment

Le Manifeste Agile et ses 12 principes fondateurs tiennent en une page. Quatre valeurs :

  • Un logiciel qui fonctionne plutôt qu’une documentation exhaustive
  • La collaboration avec le client plutôt que la négociation contractuelle
  • L’adaptation au changement plutôt que le suivi d’un plan
  • Les individus et leurs interactions plutôt que les processus et les outils

Le sprint planning, les story points, les cérémonies Scrum (mêlée quotidienne, réunion de planification, revue de sprint), le Scrum Master, les courbes de vélocité, les méthodologies agiles, le management agile, SAFe et les frameworks de mise à l’échelle : rien de tout cela n’apparaît dans le Manifeste.

Les règles créées pour intégrer l’approche agile dans les méthodes traditionnelles, alors qu’elle était censée les remplacer, sont devenues plus importantes que les principes qu’elles devaient appliquer. Le résultat se chiffre en milliards, investis dans des logiciels que personne n’utilise.

Le problème n’est pas ce que dit le Manifeste, mais le modèle de tarification et le processus de gestion de projet qui l’entourent.

Agile n’est pas un état d’esprit. C’est l’application de la méthode scientifique au développement logiciel.

Chez DEVEDANOS, dans notre démarche agile, chaque fonctionnalité est une hypothèse confrontée à la réalité de vos utilisateurs pour collecter leur feedback. Le plan et les spécifications évoluent au contact du terrain. Le processus de développement logiciel est conçu pour découvrir et s’adapter, pas pour exécuter un document que personne ne relira.

L’approche en bref

Livraison continue
Votre logiciel reste déployable au quotidien
Monitoring en production
Vous voyez tôt les pannes et l’usage réel
Boucles de retour rapides
Vous mesurez ce qui produit des résultats dès le départ
Périmètre piloté par la valeur
Vos priorités évoluent avec votre marché
Spécifications exécutables
Vos fonctionnalités validées restent stables

Ce que vous pilotez sur ce projet

Que change cette discipline pour vous, semaine après semaine ?

Approche agile : vous décidez ce qui passe en production

Priorités

L’approche classique

Un chef de projet décide, sur la base d’un document écrit il y a des mois (modèle en cascade, cycle en V)

Avec DEVEDANOS

Vous êtes le product owner : vous portez la vision du produit, vous connaissez votre marché, vous pilotez la recherche utilisateur, vous décidez ce qui a le plus de valeur en vous appuyant sur nos observations. Chaque semaine, nous choisissons ensemble la prochaine hypothèse à vérifier. Quand les besoins réels de vos utilisateurs ne correspondent pas à vos priorités, nous vous le disons

Changement de direction

L’approche classique

Avenant, surcoût, délai

Avec DEVEDANOS

Vous réorientez les priorités quand vous voulez, en toute flexibilité et réactivité. Le contrat ne change pas. Le prix non plus

Validation

L’approche classique

Livraison en bloc, en fin de projet (effet tunnel). Votre seul choix : signer le procès-verbal

Avec DEVEDANOS

Chaque fonctionnalité est validée par vous avant de partir en production. Vous approuvez, ou vous refusez

Visibilité sur l’avancement

L’approche classique

Démonstrations mensuelles. Pourcentages d’avancement déconnectés du logiciel réel

Avec DEVEDANOS

Vous ouvrez l’application à tout moment et vous utilisez ce qui est livré. Un logiciel fonctionnel en production est la principale mesure d’avancement du projet. Notre tableau kanban collaboratif et backlog sont aussi consultables en permanence

Deux tiers des fonctionnalités développées n’apportent aucune valeur mesurable. Impossible de le savoir sans les livrer.

Chaque fonctionnalité devient un produit livrable sous forme d’incrément minimal. En production, nous observons ce que font vos utilisateurs. Ce que nous apprenons décide de la suite : poursuivre, ajuster ou abandonner.

Le coût de maintenance d’une fonctionnalité représente 3 à 4 fois son coût de développement initial (Capers Jones, Applied Software Measurement, 2008). Ne rien construire d’inutile n’est donc pas un luxe. Avancer avec un périmètre flexible et un développement itératif en cycles courts est la seule réponse lean à ce gaspillage et assure la satisfaction client.

Ensemble, nous formons une équipe agile : le travail d’équipe entre vous et nous oriente chaque décision et couvre l’ensemble du cycle de vie du logiciel.

Chaque fonctionnalité est une itération : un cycle de développement complet

1

Vous décidez ce que le logiciel doit faire, nous spécifions ensemble.

Nous investiguons, planifions, assurons la priorisation et nous synchronisons en continu. Le développement logiciel est un processus de découverte permanente.

Nous identifions ensemble ce qui crée le plus de valeur pour vos utilisateurs finaux et nous le découpons au plus petit, en user stories livrables. Nous priorisons par comparaison directe de valeur. Quand la complexité du domaine l’exige, nous cartographions le territoire du problème avant de coder.

Pour chaque fonctionnalité, nous formulons des critères concrets : que doit faire le logiciel, exactement, pour que vous puissiez valider le travail ? Ces critères sont traduits en scénarios de tests automatisés, rédigés avant la première ligne de code (spécifications exécutables). Si les tests passent, la fonctionnalité devient un produit livrable. Sinon, elle ne l’est pas.

2

Chaque changement est vérifié automatiquement avant d’arriver en recette.

Chaque changement de code déclenche une chaîne d’intégration continue et de vérification automatisée (le « pipeline »). Les contrôles rapides (tests unitaires, typage, analyse statique) prennent moins de 5 minutes. Les tests d’intégration et les tests d’acceptation (tests fonctionnels), qui reproduisent le comportement attendu par vos utilisateurs, prennent moins de 30 minutes.

Un changement qui échoue à l’une de ces étapes n’atteint jamais votre environnement de recette : les défauts techniques sont interceptés en amont, et seules les fonctionnalités conformes aux critères définis à l’étape 1 vous parviennent.

3

Vous validez, nous mettons en ligne.

Vous testez chaque fonctionnalité dans un environnement de recette identique à la production. En parallèle, le pipeline exécute les audits de sécurité et les tests de performance. De la modification au verdict complet, moins d’une heure s’écoule.

Si le résultat vous convient, nous rendons la nouvelle version visible. Le code est déjà déployé via notre pipeline de déploiement automatisé et attend votre feu vert pour être activé en production. Nous visons au moins une mise en production par semaine. Rien ne passe en ligne sans votre approbation.

En environnement de production, le monitoring nous alerte en cas d’incident, sans attendre que vos utilisateurs les signalent. Nos outils d’analyse (analytics) mesurent l’impact réel de chaque fonctionnalité à travers les pirate metrics (AARRR : acquisition, activation, rétention, revenus, recommandation) et guident les prochaines décisions.

Ce que l’amélioration continue produit en 6 mois

Que constate-t-on après six mois de livraison continue ?

Vos utilisateurs restent et votre chiffre d’affaires progresse

Un logiciel validé chaque semaine par de vrais utilisateurs. Vous mesurez ce qui fonctionne, vous retirez ce qui ne sert pas, et votre investissement produit des résultats visibles dès les premières semaines.

Vous imposez le rythme à vos concurrents

Vous occupez le terrain. Vous itérez plus vite, à un rythme soutenable.

Chaque euro investi finance une fonctionnalité utilisée

Ce qui ne servait pas a été retiré en quelques jours. Le budget finance uniquement ce que vos utilisateurs utilisent.

Votre entreprise absorbe la croissance sans recruter proportionnellement

Le logiciel prend en charge ce qui aurait exigé des embauches : traitements récurrents, relances, synchronisations, reporting. Votre activité grandit et votre effectif actuel suffit, parce que le logiciel absorbe le volume supplémentaire. Les gains sont opérationnels et immédiats.

La garantie zéro régression

Chaque fonctionnalité que vous approuvez est verrouillée par un test automatisé. Si une modification ultérieure altère son comportement, le test détecte la régression avant que vos utilisateurs ne s’en aperçoivent.

L'équipe de développement corrige la régression avant le prochain déploiement.

Couvert

  • Toute fonctionnalité approuvée en recette qui change de comportement à cause d’une modification ultérieure
  • Correction déployée en heures plutôt qu’en semaines
  • Retour en arrière possible à tout moment en cas d’incident

Non couvert

  • Les demandes d’évolution (comptabilisées comme du travail courant, et non comme une régression)
  • Les dysfonctionnements de services tiers (hébergement, API externes)

15 jours pour vous faire un avis. Aucune facture si le résultat ne vous convient pas.

Le premier mois d’abonnement est une période d’essai. Nous cadrons avec vous, puis nous développons et déployons en continu. Vous recettez chaque fonctionnalité. Si vous décidez de ne pas continuer, aucune facture n’est émise et vous ne devez rien.

Photo de Sébastien Nobour, fondateur de DEVEDANOS

Sébastien Nobour

Développeur logiciel · Fondateur de DEVEDANOS

Vous travaillez avec les développeurs qui conçoivent, développent et déploient votre logiciel.

Questions fréquentes

Fournissez-vous des estimations ?
Comment fonctionne votre modèle ?
Peut-on changer les priorités en cours de route ?
Que se passe-t-il si votre intervenant principal devient indisponible ?
Quelle est la différence entre votre approche et un projet agile classique ?
Suis-je engagé sur une durée minimale ?

Prêt à voir la différence ?

Trente minutes pour comprendre votre situation. Si nous pouvons vous aider, un second rendez-vous a lieu sous 48 heures pour construire le devis ensemble.