Pourquoi nous livrons par sprints de deux semaines

« Agile » est devenu un mot qu’on met sur à peu près tout, souvent sans que ça change grand-chose côté client. Ce qui compte n’est pas le vocabulaire, c’est ce que ça change concrètement dans votre expérience de projet : ce que vous voyez, quand vous le voyez, et à quel moment vous pouvez encore changer d’avis sans que ça coûte cher.

Ce qui change pour vous, client

Avec un projet livré en une fois au bout de trois mois, vous découvrez le résultat complet à la fin — trop tard pour corriger une orientation qui ne convient pas sans repartir sur une bonne partie du travail déjà fait. Avec des sprints de deux semaines, vous voyez une version fonctionnelle toutes les deux semaines, vous la testez, et vous dites ce qui doit changer avant que ça ne devienne coûteux à corriger. La différence n’est pas cosmétique : elle change directement le niveau de risque du projet.

Les arbitrages surviennent tôt, pas à la fin

Sur un projet classique en cascade, les arbitrages budgétaires difficiles arrivent souvent à la fin, quand le budget est déjà largement engagé et que revenir en arrière coûte cher. Avec des sprints courts, ces arbitrages arrivent dès la troisième ou quatrième semaine, sur un périmètre de travail encore limité. Décider de recentrer un module ou d’ajuster une fonctionnalité au sprint 2 coûte une fraction de ce que coûte le même ajustement découvert au sprint 8.

Comment se déroule un sprint chez nous

Chaque sprint démarre par une planification courte où l’on fixe ensemble ce qui sera livré dans les deux semaines à venir, en fonction des priorités réelles du moment — pas d’un plan figé six mois plus tôt. À la fin du sprint, une démo montre ce qui a été construit, sur un environnement que vous pouvez manipuler vous-même, pas une simple présentation de captures d’écran. Une courte rétrospective ferme le sprint : ce qui a bien fonctionné, ce qui doit être ajusté pour le suivant.

Le prix de cette méthode

Cette approche a une contrepartie honnête : elle demande votre disponibilité régulière, pas seulement au lancement et à la livraison finale. Un client qui ne peut donner un retour qu’une fois par mois perd une bonne partie du bénéfice du sprint court, parce que les décisions s’accumulent sans être validées à temps. C’est un point qu’on aborde dès le premier échange, parce que la méthode ne convient pas à tous les rythmes d’organisation, et il vaut mieux le savoir avant de démarrer plutôt qu’au sprint 3.

Ce que ça change sur le budget final

Le bénéfice le plus concret, au-delà de la visibilité, c’est la maîtrise du budget. Les demandes de changement en cours de route — inévitables sur la quasi-totalité des projets — sont chiffrées et validées sprint par sprint, plutôt que découvertes en bloc à la fin sous forme d’un avenant qui fait grimper la facture d’un coup. Vous savez à tout moment où en est le budget consommé par rapport à ce qui reste à faire, ce qui évite la mauvaise surprise classique du projet web : un dépassement découvert seulement à la facturation finale.

Est-ce que ça convient à tous les projets ?

Pas nécessairement à un site vitrine très simple, où le périmètre est limité et stable dès le départ — dans ce cas, un cycle plus court et plus direct suffit. La méthode prend tout son sens sur des projets où le périmètre exact ne peut pas être figé à 100 % en amont : une plateforme métier, un site avec des intégrations complexes, ou un projet où vos propres priorités internes évoluent en cours de route. C’est précisément là qu’un projet livré en une fois devient risqué, et qu’un rythme de sprints protège à la fois votre budget et le résultat final.

Ce que vous devez prévoir de votre côté

La méthode ne fonctionne que si un interlocuteur côté client peut se rendre disponible environ une heure toutes les deux semaines pour la démo et la validation des priorités du sprint suivant. Ce n’est pas une contrainte lourde en apparence, mais c’est souvent le point qui échoue en pratique : un projet mis en pause faute de retour client pendant trois semaines perd une bonne partie du bénéfice de la méthode, parce que les sprints suivants s’enchaînent sans validation réelle des précédents. On préfère le dire clairement dès le cadrage plutôt que de le découvrir en cours de route.

« Je préfère un prix fixe et une date fixe »

C’est l’objection la plus fréquente, et elle est légitime. La réponse tient en deux points : d’abord, le prix fixe existe toujours au niveau du projet global, l’agilité concerne la manière d’y arriver, pas le budget total engagé. Ensuite, un prix fixe sur un projet en cascade ne protège pas réellement du dépassement — il déplace simplement le moment où le dépassement se révèle, sous forme d’avenants signés en urgence en fin de projet, souvent dans de moins bonnes conditions de négociation qu’en cours de route. Le sprint court ne supprime pas les imprévus d’un projet web, il les rend visibles et gérables au fur et à mesure, plutôt que de les laisser s’accumuler jusqu’à la livraison.