Le sprint agile vu du bureau du dirigeant qui paie

Pourquoi votre prestataire travaille en sprints (et ce que ça change pour vous)

Une équipe ne choisit pas de découper le travail en sprints par goût de la méthode, mais pour réduire un risque bien réel : celui d'un projet entier construit pendant six mois sur une hypothèse qui s'avère fausse le jour de la livraison. En morcelant le travail, elle vous montre le résultat toutes les deux semaines, et une erreur de direction se corrige après quinze jours perdus, pas après six mois.

Cette logique s'oppose directement à un projet vendu d'un seul tenant, décrit intégralement avant le premier jour de travail dans un logiciel sur mesure figé sur un document signé une fois pour toutes. Le document rassure au moment de la signature, puis s'use vite : votre activité change, un concurrent sort quelque chose que vous n'aviez pas anticipé, un utilisateur signale un besoin que personne n'avait vu venir. Le sprint absorbe ce changement, le document figé le subit.

Pour vous qui payez, la conséquence directe tient en une phrase : vous ne validez jamais un projet entier d'un coup, vous validez une tranche de deux semaines à la fois. C'est plus de rendez-vous, plus de décisions à prendre en cours de route, et en échange, beaucoup moins de risque de découvrir à la fin que le projet ne correspond plus à ce dont votre entreprise a besoin.

Ce fonctionnement demande une discipline de votre côté aussi : quelqu'un chez vous doit être disponible, toutes les deux semaines, pour regarder la démonstration et trancher la suite. Un sprint sans personne côté client pour juger le résultat perd une bonne partie de son intérêt, puisque la correction de trajectoire dépend justement de ce regard régulier.

L'autre bénéfice, moins visible, touche votre trésorerie : un projet découpé en sprints vous permet d'arrêter après n'importe lequel d'entre eux, avec un produit qui fonctionne, même partiellement, plutôt qu'un chantier inachevé qui ne sert à rien tant qu'il n'est pas fini. Cette réversibilité change la nature du risque que vous prenez en signant.

Ce que vous devez retenir ici, avant d'entrer dans le détail des quatre moments d'un sprint : la méthode existe pour vous protéger contre un projet qui part dans le mur pendant des mois sans que personne ne s'en aperçoive à temps.

Les quatre moments d'un sprint, vus par celui qui paie

Un sprint suit toujours le même enchaînement, dans le même ordre, et connaître cet enchaînement vous permet de savoir à quel moment vous devez intervenir et à quel moment vous devez laisser l'équipe travailler tranquille.

Premier moment : on fixe la liste avec vous. Avant que le sprint démarre, vous et l'équipe vous mettez d'accord sur ce qui sera construit pendant les deux semaines à venir, dans un ordre de priorité que vous validez. C'est le seul moment où vous décidez du contenu ; une fois le sprint lancé, la liste ne bouge plus.

Deuxième moment : l'équipe construit. Pendant dix jours ouvrés, les développeurs écrivent le code, le testent, corrigent ce qui casse. Vous n'avez normalement rien à faire à ce stade, sinon rester joignable si une question se pose sur un point que vous seul pouvez trancher, un détail métier par exemple.

Troisième moment : la démonstration sur le produit réel. C'est le rendez-vous qui compte le plus, celui où vous voyez tourner ce qui a été construit, en cliquant vous-même si vous le souhaitez. Une démonstration sur des images fixes ou une présentation n'en est pas une : exigez l'écran qui répond.

Quatrième moment : vous décidez de la suite. Fort de ce que vous venez de voir, vous validez la liste du sprint suivant, ajustée si besoin selon ce qui vous a surpris, en bien comme en mal. Ce moment referme la boucle et en ouvre une nouvelle, identique dans sa forme.

Reprenons l'exemple d'une fonctionnalité de connexion à un compte : elle part d'une liste validée un lundi, se construit pendant deux semaines, et se termine par un écran où vous tapez un mot de passe erroné et voyez le message d'erreur apparaître réellement, pas sur un dessin. C'est ce passage de l'idée à l'écran qui donne sa valeur au sprint.

Ces quatre moments se répètent à l'identique, sprint après sprint, jusqu'à ce que la liste complète du projet soit épuisée ou que vous décidiez d'arrêter. La régularité du rythme est justement ce qui vous permet de juger si le projet avance, sans avoir à ouvrir le code vous-même.

Ce que vous devez voir à la fin de chaque sprint

Cette section est celle qui compte le plus dans toute cette page, parce qu'elle vous donne les trois choses concrètes à exiger de voir, sprint après sprint, pour juger si votre argent avance réellement ou si on vous fait patienter avec de bonnes intentions.

La première chose, c'est un écran qui répond quand vous cliquez dessus. Pas une maquette, pas une image qui ressemble au futur logiciel : un écran réel, connecté à de vraies données ou à des données de test, qui réagit quand vous appuyez sur un bouton. Si personne ne peut vous montrer ça toutes les deux semaines, quelque chose ne va pas dans la façon dont le sprint est mené.

La deuxième chose, plus discrète mais tout aussi importante, c'est le code déposé dans un dépôt qui vous appartient, ou auquel vous avez accès. Ce code représente le travail payé pendant le sprint : s'il n'existe que sur l'ordinateur du développeur, vous n'avez aucune garantie qu'il existe vraiment, ni la possibilité de le reprendre avec quelqu'un d'autre le jour où ce sera nécessaire.

La troisième chose, c'est la liste du sprint suivant, déjà posée et prête à être validée. Un sprint qui se termine sans que personne ne sache ce qui démarre dans la foulée traduit souvent une équipe qui découvre le travail au fur et à mesure, plutôt qu'une équipe qui planifie.

Si l'une de ces trois choses manque à une démonstration, posez la question directement, sans détour poli : qu'est-ce qui empêche de me montrer un écran qui réagit aujourd'hui ? Une bonne réponse cite un obstacle précis et une date de rattrapage ; une réponse vague sur l'avancement global ou sur la complexité du sujet mérite votre méfiance.

Une phrase à garder en tête pour vos échanges avec votre prestataire : on vous doit un clic qui marche, pas un rapport d'avancement. Le rapport peut accompagner la démonstration, il ne peut jamais la remplacer, quelle que soit la qualité de sa mise en forme.

Ce triptyque, écran qui répond, code déposé, prochaine liste prête, ne demande aucune compétence technique pour être vérifié. Vous n'avez pas besoin de comprendre ce que le code fait pour juger s'il existe et si vous pouvez y accéder ; c'est justement ce qui rend ce contrôle accessible à un dirigeant qui n'a jamais écrit une ligne.

Combien de temps avant d'avoir un produit qui sert vraiment

Un sprint isolé construit un morceau, jamais un produit entier. Ce qui vous intéresse, en tant que dirigeant, c'est la somme de plusieurs sprints : combien il en faut avant d'avoir entre les mains quelque chose que vos équipes ou vos clients peuvent réellement utiliser, pas seulement regarder.

Pour un premier produit complet, la fourchette habituelle se situe entre trois et six sprints, soit six à douze semaines. Ce délai varie selon la taille de l'équipe engagée sur votre projet et la complexité de ce que vous demandez : un formulaire de contact avec envoi de courriel se construit plus vite qu'un outil qui doit se connecter à votre logiciel de facturation existant.

Les premiers sprints ressemblent rarement à ce que vous imaginiez au départ : ils posent les fondations, les écrans de connexion, la structure de la base de données, des choses peu spectaculaires à voir mais sans lesquelles la suite ne tienne debout. La partie visible, celle qui ressemble vraiment à votre futur outil, apparaît le plus souvent à partir du deuxième ou du troisième sprint.

Méfiez-vous d'une promesse de produit fini en un seul sprint, sauf si votre besoin est vraiment minuscule. Un projet qui annonce un résultat complet en deux semaines a soit sous-estimé le travail, soit prévu de vous montrer une version qui ne tiendra pas devant de vrais utilisateurs.

À l'inverse, méfiez-vous tout autant d'un enchaînement de sprints qui dépasse largement les six mois sans qu'un seul morceau ne serve vraiment à votre activité quotidienne. Passé ce délai, une partie du projet mérite d'être mise en service, même partiellement, pour commencer à en tirer un bénéfice pendant que le reste continue de se construire.

Ce rythme, trois à six sprints pour un premier produit utilisable, sert de repère pour vos échanges avec votre prestataire : demandez-lui, dès le premier rendez-vous, à quel sprint il situe la première mise en service réelle, même partielle, de ce que vous payez.

Combien coûte un sprint, et comment lire un devis qui en contient plusieurs

Le sujet du prix mérite d'être traité de front, puisqu'il s'agit ici d'une décision d'achat et que tourner autour ne rendrait service à personne. Un devis qui parle de sprints sans jamais donner de chiffre concret laisse le dirigeant deviner, et deviner coûte cher au moment de signer.

Chez Techmind, un sprint mobilise entre douze et vingt-cinq jours de travail selon la taille de l'équipe engagée sur votre projet, un développeur seul ou plusieurs en parallèle. Ce volume de jours se convertit ensuite en montant sur devis selon le taux journalier retenu pour votre chantier, et s'inscrit dans nos offres de construction, pensées justement pour un fonctionnement en sprints réguliers.

Pour lire un devis qui annonce plusieurs sprints, une seule règle : multipliez le nombre de sprints par le coût d'un sprint, et vérifiez que le total correspond à ce qu'on vous demande de signer. Si le devis annonce un montant global sans jamais détailler combien de sprints il couvre, demandez le détail avant de signer quoi que ce soit.

Le nombre de jours par sprint varie surtout avec deux facteurs : la taille de l'équipe posée sur votre projet, et la difficulté technique du travail demandé. Une fonctionnalité qui touche à des données sensibles ou à un système existant compliqué demande davantage de jours de vérification qu'un écran isolé qui ne parle à rien d'autre.

Méfiez-vous d'un devis qui annonce un prix par sprint anormalement bas comparé au reste du marché : soit l'équipe est réellement plus rapide pour des raisons vérifiables, soit une partie du travail attendu, les tests, la documentation, la correction des défauts, a été retirée du sprint pour faire baisser le chiffre affiché.

Ce prix par sprint s'inscrit dans une fourchette plus large : un premier outil complet, construit sur plusieurs sprints, se situe en général entre 15 000 et 50 000 euros selon son ampleur. Le prix du sprint isolé vous aide à vérifier, chemin faisant, que le total ne dérive pas loin de cette fourchette annoncée au départ.

Retenez surtout ceci : un devis en sprints qui refuse de vous donner un prix par sprint, même approximatif, retire l'un des principaux avantages de la méthode pour vous, celui de pouvoir suivre votre budget au fil de l'eau plutôt que de le découvrir à la fin.

Sprint agile ou cahier des charges figé : ce que chacun vous fait risquer

Face à un nouveau projet, deux façons de commander existent, et chacune vous fait courir un risque différent, jamais nul dans les deux cas. Comprendre lequel vous acceptez, plutôt que de subir un vocabulaire technique, vous permet de choisir en connaissance de cause.

Un cahier des charges figé décrit, avant le premier jour de travail, tout ce que le futur outil doit faire, dans un document signé une fois. Le risque qu'il vous fait porter : ce document décrit ce que vous pensiez vouloir au moment de la signature, pas nécessairement ce dont votre entreprise aura besoin six mois plus tard, une fois le projet livré. Vous découvrez l'écart à la toute fin, au pire moment pour le corriger.

Un sprint vous fait porter un risque différent : celui de payer, toutes les deux semaines, la disponibilité nécessaire pour trancher et valider la suite. Sans quelqu'un chez vous pour occuper ce rôle régulièrement, le projet avance à l'aveugle malgré la méthode, puisque personne ne corrige la trajectoire au moment où elle dévie.

Le cahier des charges figé convient mieux à un besoin déjà bien connu, stable, peu susceptible de changer pendant la construction, une déclaration administrative obligatoire par exemple. Le sprint convient mieux dès que le besoin réel ne se révèle qu'en voyant l'outil tourner, ce qui couvre la majorité des projets de développement sur mesure qu'une PME commande aujourd'hui.

Le sujet du document qui décrit précisément ce qu'un projet doit contenir, ses limites, ses exclusions, mérite sa propre page : notre guide sur le cahier des charges détaille comment l'écrire sans lui faire porter un poids qu'il ne peut pas tenir, y compris dans un projet mené en sprints.

Dans la pratique, beaucoup de projets mélangent les deux : un cahier des charges léger fixe le cap général et le budget, puis chaque sprint affine le détail au fur et à mesure. Le choix n'oppose pas les deux outils l'un à l'autre, il porte sur la place que vous laissez au changement en cours de route, et sur qui, chez vous, assume de le décider.

Ce qui ne bouge pas pendant un sprint : le cadre qui protège votre budget

Un sprint protège votre budget par un principe simple, presque brutal : une fois la liste arrêtée au premier jour, elle ne bouge plus jusqu'à la démonstration, quinze jours plus tard. Aucune demande nouvelle ne s'ajoute en cours de route, même si elle paraît urgente sur le moment.

Cette rigidité n'est pas un caprice d'équipe technique, elle vous protège directement : sans elle, chaque sprint accueillerait des demandes ajoutées au fil de l'eau, sans jamais finir ce qui avait été promis au départ, et sans que personne ne puisse dire, à la fin, pourquoi rien n'est vraiment terminé.

Quand une idée nouvelle surgit en cours de sprint, la bonne pratique consiste à la noter pour le sprint suivant, jamais à l'insérer dans celui en cours. Cette règle vaut aussi bien pour vos demandes que pour celles de l'équipe technique : personne ne rouvre la liste une fois le sprint lancé.

Si la liste est rouverte malgré tout, en général sous la pression d'un dirigeant pressé, la démonstration suivante glisse d'autant de jours que le retard pris par l'ajout imprévu. Ce glissement n'a rien de mystérieux : le temps passé sur la demande ajoutée est retiré du temps prévu pour le reste, et se paie en retard, pas en magie.

Une vraie urgence, un bug qui bloque votre activité par exemple, se traite en dehors du cadre du sprint, comme une intervention à part, pas comme un ajout à la liste en cours. Un bon prestataire distingue les deux : l'urgence réelle qui justifie d'interrompre le travail, et la demande qui peut attendre quinze jours sans dommage.

Ce cadre qui semble contraignant au premier abord est, en réalité, ce qui vous permet de savoir combien coûtera votre projet et quand il sera livré. Sans lui, chaque sprint deviendrait un sac sans fond où s'accumulent les bonnes idées, sans qu'aucune ne soit jamais vraiment terminée.

Trois signes qu'un sprint est un sprint de façade

Le mot sprint se galvaude facilement : certains prestataires l'emploient pour habiller un fonctionnement classique, sans qu'aucun des bénéfices réels de la méthode ne vous parvienne. Trois signes trahissent un sprint de façade, et les trois se repèrent sans compétence technique.

Premier signe : aucune démonstration qui clique. On vous montre des captures d'écran, un document de suivi, une liste de tâches cochées, mais jamais un écran sur lequel vous pouvez appuyer vous-même. Sans ce clic réel, vous n'avez aucune preuve que le travail annoncé existe vraiment sous une forme utilisable.

Deuxième signe : le mot sprint sert d'excuse à un retard plutôt que de désigner une étape franchie. On est dans le sprint 4, ça avance, ne dit rien si personne ne peut préciser ce que le sprint 4 a produit de concret par rapport au sprint 3. Le vocabulaire remplace alors l'information qu'il devrait porter.

Troisième signe : le code que vous ne pouvez jamais consulter, dans un dépôt qui vous appartient ou auquel vous avez accès direct. Un sprint honnête livre du code vérifiable à chaque fin de cycle ; un sprint de façade garde ce code hors de votre portée, sous prétexte de complexité technique ou de confidentialité mal justifiée.

Ignorés pendant plusieurs sprints d'affilée, ces trois signes annoncent souvent un problème plus large que le simple rythme de travail : une dette technique qui s'installe sans que personne ne la mesure, parce que personne ne regarde jamais vraiment ce qui a été construit. Le sprint de façade et la dette cachée se nourrissent l'un l'autre.

Si vous repérez l'un de ces trois signes, la réaction la plus utile reste la plus simple : demandez la démonstration suivante par écrit, avec une date précise, et jugez sur ce qui se passe réellement ce jour-là, pas sur la promesse qui précède.

Reprendre la main si un sprint ne s'est pas passé comme prévu

La réversibilité est l'un des vrais bénéfices d'un projet mené en sprints, et elle se joue entre deux sprints consécutifs, jamais en cours de route. Vous n'êtes jamais engagé sur un projet entier avant de l'avoir vu avancer.

Concrètement, vous engagez la suite du travail seulement une fois que vous avez vu, de vos yeux, ce que le sprint précédent a réellement produit. Si le résultat vous convainc, vous validez la liste suivante. Si quelque chose vous inquiète, vous en discutez avant de valider quoi que ce soit, sans avoir déjà payé pour un travail qui ne vous convient pas.

Vous pouvez, en théorie comme en pratique, arrêter à la fin de n'importe quel sprint. Ce que vous récupérez à ce moment-là n'est pas un chantier à moitié fait et inutilisable, mais un produit qui fonctionne, même sous une forme réduite par rapport à votre ambition de départ, puisque chaque sprint livre un morceau qui tourne réellement.

Le premier ou les deux premiers sprints livrent souvent la version la plus simple d'un produit, avant qu'on l'enrichisse au fil des sprints suivants. Cette version minimale porte un nom que vous croiserez chez de nombreux prestataires, celui de MVP, et notre page dédiée le détaille pour qui veut aller plus loin sur ce point précis.

Un arrêt qui se passe bien se traduit par quelques éléments concrets : le code vous est remis dans son état actuel, l'accès aux comptes techniques vous revient, et rien ne vous engage à continuer au-delà du sprint qui vient de se terminer. Un prestataire qui rend cet arrêt difficile, par des clauses ou par un flou volontaire sur l'accès au code, retire une bonne part de l'intérêt de travailler en sprints.

Cette possibilité de s'arrêter, sprint après sprint, ne se discute pas comme une clause cachée dans un contrat : elle se pose avant la première signature, avec votre prestataire, pour savoir précisément ce que vous récupérez si vous décidez de ne pas continuer.

Ce que vous pouvez vérifier dès le prochain point avec votre prestataire

Cette page vous a donné beaucoup d'éléments ; voici comment les mobiliser concrètement, dès votre prochain échange avec votre prestataire, sans avoir besoin de relire l'ensemble du texte à chaque fois.

Demandez à voir un écran qui répond réellement à un clic, pas une image ni une présentation, pour le dernier sprint terminé. Si la réponse hésite ou renvoie à un futur rendez-vous, notez-le : c'est une donnée, pas un détail.

Demandez l'accès au dépôt où le code est déposé, à votre nom ou à celui de votre entreprise. Un prestataire à l'aise avec cette demande la traite comme une évidence ; un prestataire qui la contourne ou la reporte mérite une question de plus.

Demandez la liste du sprint qui vient de démarrer, ou qui va démarrer, et vérifiez qu'elle a été validée avec vous et non décidée seule dans son coin par l'équipe. Cette liste est votre principal outil de suivi budgétaire, plus utile que n'importe quel rapport d'avancement rédigé après coup.

Demandez enfin un prix par sprint, même approximatif, si votre devis ne l'indique pas déjà. Ce chiffre vous permet de suivre votre budget au fil de l'eau, sprint après sprint, plutôt que de découvrir un dépassement une fois le projet terminé.

Ces quatre questions ne demandent aucune compétence technique pour être posées, ni pour juger la réponse qu'elles obtiennent. Elles suffisent, dans l'immense majorité des cas, à distinguer un sprint qui fait réellement avancer votre projet d'un sprint qui se contente d'en porter le nom.