Pourquoi les transformations « agiles » échouentsans la livraison continue de fonctionnalités
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, 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, 20205,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, 202610 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, 2013En 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 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 sont devenues plus importantes que les principes qu’elles devaient servir. 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.
Chez DEVEDANOS, dans notre démarche agile, nous construisons chaque fonctionnalité comme une hypothèse à vérifier, nous la confrontons à la réalité de vos utilisateurs, et nous adaptons le produit en fonction de ce que nous observons. Le plan évolue au contact du terrain. Les spécifications évoluent avec lui. Le processus de développement est conçu pour apprendre, plutôt que pour exécuter un document que personne ne relira.
Comment nous travaillons
Approche agile : nous décidons ensemble quoi construire
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)
Notre approche
Vous êtes le product owner : vous connaissez votre marché, vous pilotez la recherche utilisateur, vous décidez ce qui a le plus de valeur. Chaque semaine, nous choisissons ensemble la prochaine hypothèse à vérifier. Nous observons ce que les utilisateurs font réellement dans le logiciel. Quand leurs besoins ne correspondent pas à vos priorités, nous vous le disons
Changement de direction
L’approche classique
Avenant, surcoût, délai
Notre approche
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
Notre approche
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
Notre approche
Vous ouvrez l’application à tout moment et vous utilisez ce qui est livré. Un logiciel fonctionnel en production est la principale mesure d’avancement. Notre tableau kanban 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. Nous construisons donc chaque idée sous forme d’incrément minimal, nous la mettons en production, et 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é inutile représente 3 à 4 fois son coût de développement initial (Capers Jones, Applied Software Measurement, 2008). Le périmètre flexible et le développement itératif ne sont pas un luxe : c’est le seul mécanisme lean qui coupe cette hémorragie et assure la satisfaction client. Ensemble, nous formons une équipe agile. Les pratiques agiles que nous appliquons couvrent l’ensemble du cycle de vie du logiciel.
Chaque fonctionnalité est une itération : un cycle de développement complet
Nous définissons ensemble ce que le logiciel doit faire.
Nous investiguons, planifions et nous synchronisons en continu, à travers le travail lui-même.
Nous identifions ce qui a le plus de valeur pour vos utilisateurs maintenant et nous le découpons en user stories livrables.
Pour cette 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 tests automatisés. Si les tests passent, le travail est livrable. Sinon, il ne l’est pas.
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’acceptation et tests d’intégration, 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. Seules les fonctionnalités conformes aux critères définis à l’étape 1 vous parviennent.
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.
Si le résultat vous convient, nous rendons la nouvelle version visible pour vos utilisateurs. Le code est déjà déployé via un déploiement automatisé (Git, Docker, GitLab CI), il attend votre feu vert pour être activé. Idéalement, au moins une mise en production par semaine. Rien ne passe en ligne sans votre approbation.
Ce que l’amélioration continue produit en 6 mois
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.
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.
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.
La personne qui a écrit le code est celle qui vous répond.
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
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)
Votre budget mensuel est fixe et connu dès le premier échange. Nous le définissons ensemble lors de l’entretien découverte, pour 15 jours de développement par mois.
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 le travail ne vous convainc pas, aucune facture n’est émise et vous ne devez rien.
Sébastien Nobour
Développeur logiciel · Fondateur de DEVEDANOS
La personne qui écrit le code est votre interlocuteur.
Questions fréquentes
Fournissez-vous des estimations ?
Nous ne fixons pas un nombre de jours par fonctionnalité. Nous fixons votre budget mensuel et notre engagement à livrer chaque semaine les fonctionnalités qui ont le plus de valeur pour votre activité. Vous testez, vous approuvez, nous déployons. Si vos priorités changent, nous changeons avec vous. Vous connaissez votre dépense exacte avant de commencer : un budget mensuel fixe, que nous déterminons ensemble lors de l’entretien découverte. Le contenu de chaque livraison, en revanche, évolue au contact de la réalité, parce que vos priorités évolueront. Et c’est précisément ce qui vous protège.
Comment fonctionne votre modèle ?
Un budget mensuel fixe, un périmètre flexible. Quand le périmètre, le budget et les délais sont figés en même temps, le projet n’a aucune marge d’adaptation. Le modèle de tarification à l’estimation fige le périmètre avant que quiconque ne comprenne le problème. Les fonctionnalités manquantes deviennent un deuxième contrat, et le code fragile génère de la maintenance facturable.
Nous fixons le budget mensuel et nous livrons chaque semaine les fonctionnalités qui ont le plus de valeur pour votre activité. Vous changez de direction quand vous voulez, sans avenant. Vous recettez chaque fonctionnalité avant la mise en production. Et vous pouvez mettre fin à l’abonnement à tout moment par simple écrit.
Peut-on changer les priorités en cours de route ?
À tout moment. Vous réorientez les priorités quand vous voulez, le contrat ne change pas, le prix non plus. Chaque semaine, nous choisissons ensemble la prochaine hypothèse à vérifier.
Que se passe-t-il si votre intervenant principal devient indisponible ?
Le pipeline de livraison continue est la documentation vivante du projet : automatisation des tests qui décrivent le comportement métier attendu, déploiement continu sur plusieurs environnements, infrastructure as code. Un développeur compétent peut reprendre le développement en quelques jours sur un projet dont la suite de tests passe au vert et dont le déploiement s’exécute en un clic. Le code source, l’infrastructure, le pipeline de déploiement et la documentation sont votre propriété intellectuelle dès le premier paiement. Le pipeline continue de vérifier chaque modification future, quel que soit le développeur qui intervient.
Quelle est la différence entre votre approche et un projet agile classique ?
Un projet agile classique fixe le périmètre dans un backlog, découpe le travail en sprints, et mesure la vélocité de l’équipe. Le développement itératif produit des incréments, mais le périmètre reste verrouillé par le contrat initial. Notre approche maintient un budget fixe et un périmètre flexible : l’équipe de développement livre chaque semaine les fonctionnalités qui ont le plus de valeur. Les priorités changent avec votre marché, pas avec un document écrit il y a des mois. Nous nous engageons à maintenir le logiciel dans un état déployable en permanence et à livrer un logiciel fonctionnel en production chaque mois.
Suis-je engagé sur une durée minimale ?
Aucune. 15 jours pour vous faire un avis. Aucune facture si le résultat ne vous convient pas. Ensuite, l’abonnement est mensuel, résiliable à tout moment par simple notification écrite. Budget mensuel défini ensemble selon votre projet.
Prêt à voir la différence ?
30 minutes. Nous écoutons votre problème et nous vous disons si nous pouvons aider.