Méthodologie agile : ce que ça change concrètement pour vous
Tout le monde dit travailler en agile. Voici ce que cela veut dire en pratique côté client : ce que vous gagnez, ce que cela vous demande, et les cas où un forfait classique vous protège mieux.
Le vrai sujet n'est pas la méthode, c'est qui porte le risque
Derrière le mot « agile » il y a une question très concrète : que se passe-t-il quand le projet ne se déroule pas comme prévu ? Et il ne se déroule jamais exactement comme prévu.
Dans un projet classique, on définit tout au départ, on signe un prix ferme, et le prestataire porte le risque de dépassement. C'est confortable — jusqu'au moment où vous vous rendez compte au cinquième mois qu'une fonction essentielle manque et que l'ajouter demande un avenant.
En agile, on définit une direction et un budget, et on décide au fur et à mesure de ce qu'on construit avec ce budget. Vous portez plus de responsabilité, et en échange vous gardez la main sur les priorités jusqu'au dernier moment.
Forfait ou agile : lequel vous protège le mieux ?
Il n'y a pas de bonne réponse dans l'absolu. Cela dépend de votre projet et de votre disponibilité.
| Forfait classique | Agile par sprints | |
|---|---|---|
| Le périmètre | Figé à la signature | Ajustable à chaque sprint |
| Le prix | Ferme | Plafonné par le budget, contenu variable |
| Qui porte le risque | Le prestataire | Partagé |
| Ce qu'on vous demande | Peu de disponibilité | Une validation toutes les deux semaines |
| Un changement d'avis | Avenant à négocier | Arbitrage au sprint suivant |
| À choisir quand | Le besoin est clair et daté | Le produit va évoluer en le construisant |
En pratique, beaucoup de projets fonctionnent bien en combinant les deux : un forfait sur le cadrage et le design, où le périmètre est net, puis des sprints sur le développement, où les priorités bougent.
Ce que vous voyez, concrètement, toutes les deux semaines
Une démo de ce qui fonctionne
Pas une présentation ni une maquette : le produit, utilisable, sur un environnement de test. Si on ne peut pas vous le montrer en fonctionnement, ce n'est pas terminé.
Ce qui a été fait et ce qui reste
La liste des tâches terminées, celles en cours et celles à venir, avec la charge restante. Vous savez où va le budget.
Les arbitrages à rendre
Les décisions qui vous appartiennent, posées clairement, avec le coût de chaque option. C'est là que vous pilotez réellement le projet.
Ce que l'agile ne fait pas
Il faut aussi dire ce que la méthode ne résout pas, parce que « on est en agile » sert parfois à justifier l'inverse de ce qu'elle prétend.
- Ce n'est pas une excuse pour ne pas cadrer. Un projet agile a une direction, un budget et des hypothèses écrites. Sans cadrage, l'agilité devient de l'improvisation facturée.
- Ce n'est pas un budget élastique. Le budget est plafonné. Ce qui varie, c'est ce qu'on met dedans.
- Ce n'est pas sans documentation. Un projet sans documentation vous rend dépendant de ceux qui l'ont écrit, ce qui est exactement ce qu'on cherche à éviter.
- Ce n'est pas gratuit en temps. Si personne chez vous ne peut valider en quinze jours, l'agile perd son intérêt et le forfait redevient plus adapté.
Comment nous l'appliquons
Sprints de deux semaines, démo à la fin de chacun, et un référent Yeeply présent à ces démos pour comparer l'avancement au chiffrage initial. Les priorités du sprint suivant se décident avec vous, à la lumière de ce qui vient d'être livré.
Le détail étape par étape est sur notre page processus de développement.
Questions fréquentes
L'agile coûte-t-il plus cher ?
Pas en soi. Le budget est plafonné dans les deux cas. La différence est que l'agile évite de payer pour des fonctionnalités décidées six mois plus tôt et devenues inutiles, ce qui représente souvent une part significative d'un cahier des charges initial.
Combien de temps dois-je y consacrer ?
Comptez une à deux heures par sprint : la démo, plus quelques validations entre-temps. Si vous ne pouvez pas garantir cette disponibilité, dites-le au cadrage et nous partirons plutôt sur un forfait.
Peut-on avoir un prix ferme en agile ?
On peut plafonner le budget et le délai, ce qui revient au même du point de vue de votre trésorerie. Ce qui ne peut pas être garanti à l'avance, c'est la liste exacte des fonctionnalités livrées dans cette enveloppe.
Que se passe-t-il si le budget est épuisé avant la fin ?
Cela ne devrait pas être une surprise : la charge restante est visible à chaque sprint. Quand on approche de la limite, on arbitre — soit on s'arrête avec un produit utilisable, soit vous décidez d'ajouter du budget. C'est justement pour cela qu'on construit d'abord l'essentiel.
Scrum, Kanban, autre chose ?
Peu importe le nom. Ce qui compte est qu'il y ait des cycles courts, une démo de ce qui fonctionne à la fin de chacun, et une liste de priorités visible. Le vocabulaire de la méthode n'a aucune importance pour vous.
Un projet à cadrer ?
Nous vous dirons franchement lequel des deux modes convient à votre situation, y compris si c'est le forfait.