Dossiers
Chroniques
Guides et carnets
Évènements
Tech In Sport
Green Tech Leaders
Alliancy TV
Alliancy Elevate
What’s next CIO ?
Les trophées Alliancy
Tous nos articles
Cybersécurité
Data & IA
DSI & transfo IT
International
Guerre des talents
Nominations
Numérique responsable
Politique publique
Innovation
Alliancy Studio
Alliancy Le Mag
À l’USI 2025, Frédéric Leguédois a défendu une vision radicale du développement logiciel : exit les estimations, exit les plannings. Face à un produit vivant, imprédictible par nature, seul compte ce qu’on fait maintenant. Et surtout : ce que veulent les utilisateurs.
Frédéric Leguédois ne s’embarrasse pas d’euphémismes. Ce lundi 2 juin, sur la scène de l’USI, le coach agile entame fort : “Le backlog, ce n’est pas un planning mis à la verticale dans Jira (un système de suivi des bugs, de gestion des incidents et de gestion de projets développé par Atlassian)”. Sa définition du backlog correspond à une liste priorisée d’éléments par ordre décroissant d’importance, permettant de distinguer instantanément ce qui est prioritaire de ce qui ne l’est pas. Sa prise de parole dézingue, avec humour et méthode, des années de gestion projet fondée sur le fantasme de la prévisibilité. Dans cette 17ème édition, consacrée à la part incalculable du numérique, l’expert plaide pour un changement de regard : considérer le logiciel comme un projet mouvant et le backlog comme un moyen d’agir. Le constat de départ est alarmant, dans le monde du développement les estimations peuvent atteindre une marge d’erreur de 4000%. Pour lui, le premier malentendu réside dans la perception du logiciel comme un objet manufacturé. “À chaque fois que vous développez un logiciel, c’est la première fois que vous le faites. Sinon, vous l’auriez déjà installé.”, prévient Leguédois. Le développement logiciel s’apparente bien plus à de la R&D (recherche et développement) qu’à de la production. Il avance par exploration, pas par exécution. La conséquence ? Tous les calculs de coûts, de charges ou de ROI (return on investment) reposent sur des bases fantaisistes. “On divise une estimation de gains fantaisistes par une estimation de coûts fantasques, et on obtient… un retour sur investissement parfaitement farfelu », déplore le coach agile.
Backlog mouvant, backlog utile
Le cœur du message, c’est le backlog comme outil d’action immédiate. Pas comme projection, ni comme tableau de promesses. “La vérité du backlog est éphémère. Elle devient fausse le temps d’avoir terminé cette phrase.”, assure Leguédois. Cette liste de tâches sert à répondre à une seule question : qu’est-ce qu’on développe maintenant ? Et la réponse ne se trouve pas dans un tableur, mais chez les utilisateurs. En ce sens, le coach prône une méthode simple, presque triviale : “On liste les irritants et on leur demande quels sont les plus urgents. On choisit une solution simple et on la met en œuvre tout de suite. » Cette remise en question va jusqu’au modèle économique. Au lieu de vendre un périmètre figé à un prix fixe, l’intervenant suggère une logique radicalement différente : prix fixe, délai fixe… mais un contenu variable. Comme un abonnement à un panier de saison, où le contenu varie selon la récolte. Chaque itération devient donc une preuve de valeur, et, si, la qualité n’est pas au rendez-vous, le client part. Ce rapport de confiance oblige à produire de la qualité, pas à livrer des Powerpoints. “Le backlog n’est pas une feuille de route, c’est une boussole », conclue le coach agile. En clôturant sa conférence, Frédéric Leguédois renverse les habitudes mentales qui figent le logiciel dans des cases industrielles. Dans un contexte où les cycles courts, l’IA générative et les usages fragmentés imposent de l’adaptabilité, son message fait mouche. La valeur ne se prédit pas, elle se découvre.
3 questions à Frédéric Leguédois
Conférencier, coach agile, formateur
Qu’est-ce qui vous a conduit à abandonner les estimations dans vos projets ?
J’ai arrêté les estimations en 2009, à une époque où, comme beaucoup de développeurs, je constatais que la programmation était une activité fondamentalement imprédictible. Mais ce qui a vraiment déclenché ce changement, c’est une opportunité : celle de créer une équipe de développement de toutes pièces, avec une autonomie totale. Mon supérieur direct était un directeur artistique, extérieur au monde IT, ce qui m’a offert une liberté rare pour expérimenter. Nous avons ainsi fonctionné pendant cinq ans sans faire la moindre estimation. C’est cette expérience qui m’a montré que c’était possible… mais aussi que c’était loin d’être simple. En réalité, les estimations sont la pierre angulaire de tous les mécanismes classiques de gestion : décision, vente, contractualisation, synchronisation… tout repose dessus. Les retirer revient à faire tomber tout un système. Il ne suffit pas d’arrêter d’estimer ; il faut reconstruire, pour chaque besoin, une solution alternative.
Comment avez-vous convaincu vos clients et votre hiérarchie de passer au “no estimate” ?
La clé, c’est de ne jamais vendre le “no estimate” en tant que tel. Dire à un client : « Nous ne faisons pas d’estimations », c’est anxiogène. À l’inverse, nous mettons en avant deux engagements très concrets : un prix fixe mensuel, sans dépassement budgétaire et une flexibilité totale, le client peut changer d’avis à tout moment. C’est là que la magie opère. Le modèle devient celui d’un abonnement : on sait ce que l’on paie, mais pas exactement ce que l’on recevra, car cela dépend des besoins qui évoluent. Et ça plaît énormément aux clients… surtout ceux qui ont déjà vécu les limites du contrat au forfait. Ce dernier, en apparence protecteur, devient un piège. Dès que le client souhaite ajuster ses demandes, ce qui est inévitable dans un projet logiciel, le prestataire est en droit de répondre : “Ce n’était pas prévu dans le contrat. Il faudra payer plus”. Cela crée des tensions. Le client devient passif, il pense que le prestataire gérera seul le projet et se décharge de son implication, ce qui nuit à la qualité finale. Quant au prestataire, il devient méfiant et voit chaque nouvelle demande comme un risque pour sa rentabilité.
Du côté des ESN ou des dirigeants, la démonstration est opérationnelle : ça marche. La relation devient plus fluide, les demandes des clients sont accueillies sans passage par les circuits commerciaux ou juridiques, et surtout, le client devient un partenaire actif. C’est là que l’alignement des intérêts se produit : plus le client s’implique, plus il en retire de valeur, pour un budget constant.
Comment passe-t-on concrètement d’un fonctionnement prédictif à un mode adaptatif ?
Prenons un exemple très concret : la question de la visibilité. Les organisations veulent savoir où en est un projet, ce qui avance, ce qui va sortir. En mode classique, la réponse est toute trouvée : on fait un planning. On trace une ligne, on y met des dates, et on promet qu’à telle échéance, telle fonctionnalité sera prête. Mais très vite, parfois en quelques heures à peine, ces dates deviennent obsolètes. Une nouveauté, un imprévu, un besoin qui évolue… et tout le planning s’effondre. Cet outil devient un boomerang : on le lance pour générer de la confiance, il revient en générant du doute.
Dans une logique adaptative, on ne promet pas l’avenir : on montre le présent. La visibilité est apportée par des actions concrètes. Par exemple, en livrant une nouvelle mise à jour du logiciel chaque semaine. Quand les utilisateurs, la direction ou les financeurs voient ces livraisons fréquentes, ils comprennent que ça avance. Mieux encore, des démonstrations régulières permettent de recueillir des retours avant même les mises à jour. Et des versions bêta peuvent être proposées à un panel restreint pour tester les nouveautés sans risque. Ces pratiques apportent une visibilité sincère, fondée sur du réel, et non sur des projections fragiles. En résumé, le prédictif vend des promesses ; l’adaptatif montre des résultats. Et c’est précisément ce changement de posture qui permet de regagner la confiance.
