Le tout-forfait rassure sur le prix et fige le contenu. Le tout-agile laisse la porte ouverte aux bonnes idées mais rend le budget imprévisible. La méthode appliquée ici prend le meilleur des deux : un cadre verrouillé en amont, de la souplesse au milieu, une livraison encadrée à la fin.
Le principe
Les deux approches classiques échouent pour des raisons opposées. L'une empêche de corriger ce qu'on découvre en cours de route, l'autre empêche de savoir où l'on va s'arrêter.
Le forfait rigide : tout est décidé au départ, quand vous en savez le moins sur votre propre projet. La moindre évolution devient un avenant, et le site livré ressemble à ce que vous imaginiez six mois plus tôt.
L'agilité sans cadre : le périmètre bouge à chaque réunion, le budget suit, et personne ne sait dire quand ce sera fini. Un modèle qui fonctionne dans une équipe produit interne, rarement dans une relation client.
Un prix ferme et un périmètre écrit avant la première ligne de code : vous savez ce que vous payez et ce que vous recevez.
De la souplesse à l'intérieur de ce cadre : les priorités se réarbitrent à chaque fin de sprint, sans renégocier le contrat. Ce qui s'avère inutile est remplacé par ce qui manque.
Une date de livraison tenue, parce que la recette est planifiée dès le cadrage et non improvisée à la fin.
Déroulé
Le cadrage et la recette suivent une logique séquentielle : on verrouille, on valide, on avance. Seule la phase centrale — celle où les découvertes arrivent — fonctionne en itérations.
Recueil du besoin, définition précise du périmètre, du budget et du planning, puis validation écrite. Le référencement technique et les contraintes propres au mobile sont posés ici, pas plus tard.
Développement par lots, en sprints d'une à deux semaines. Chaque sprint produit quelque chose que vous pouvez tester. Le backlog reste priorisable : un ajustement ne remet pas en cause l'ensemble du projet.
Tests sur checklist, corrections, formation à l'administration puis mise en production. La date est ferme, et la checklist est connue de vous dès la phase de cadrage.
Les rituels
Quatre rendez-vous, pas davantage. L'objectif n'est pas de multiplier les réunions mais de garantir qu'aucune dérive ne dure plus de deux semaines sans être vue.
Les tâches du sprint sont sélectionnées dans le backlog et engagées. Vous savez précisément ce qui sera livré dans deux semaines.
Au début de chaque sprintUn échange court en visio : ce qui avance, ce qui bloque, ce qui attend une décision de votre part. Quinze à trente minutes suffisent.
HebdomadaireLe travail du sprint est présenté sur un environnement de test, que vous manipulez vous-même. C'est le moment où les priorités du sprint suivant se décident.
À chaque fin de sprintUn temps d'analyse interne sur ce qui a ralenti le sprint. Vous n'y participez pas, mais vous en voyez les effets sur la fluidité des suivants.
À chaque fin de sprintAdaptation
Un site vitrine, une digitalisation de processus et une campagne de référencement n'ont ni le même rythme ni les mêmes points de blocage. Le cadre reste identique, les réglages changent.
| Prestation | Cadrage initial | Cycle de réalisation | Suivi | Point d'attention |
|---|---|---|---|---|
| Site web | Arborescence et maquettes validées | Sprints d'une à deux semaines, par lot de pages ou de fonctionnalités | Démonstration hebdomadaire ou bimensuelle | Le référencement est intégré dès le cadrage, jamais rattrapé après coup |
| Digitalisation | Cartographie des processus existants | Sprints de deux semaines, priorisés par valeur métier | Comité de pilotage bimensuel | La conduite du changement s'anticipe : un outil que personne n'utilise n'a rien résolu |
| Application mobile | Spécifications et contraintes iOS / Android | Sprints de deux semaines, versions bêta installables | Démonstration sur appareil réel à chaque sprint | Les délais de validation Apple et Google se réservent au planning dès le départ |
| SEO & SEA | Audit initial et choix des indicateurs | Cycles courts en flux continu, sans « fin de projet » | Rapport mensuel et point stratégique trimestriel | Travail continu, indépendant du planning de refonte du site |
Rôles
La méthode ne fonctionne qu'à une condition : qu'une personne, côté client, soit identifiée et disponible pour trancher. C'est le point qui fait dérailler la majorité des projets, bien avant la technique.
Côté MH WebConsulting : priorise le backlog, arbitre avec vous, garantit le respect du planning et du budget. C'est aussi la personne qui développe — pas un intermédiaire qui transmet.
Un seul interlocuteur, du cadrage à la maintenanceCôté vous : valide les livrables, hiérarchise les besoins métier, tranche quand deux options sont possibles. Une personne, pas un comité — les décisions collégiales à cinq bloquent les sprints.
Environ deux heures par sprintSelon le projet : rédacteur, photographe, expert-comptable, avocat, prestataire déjà en place. Ils sont associés au moment utile et repartent avec des consignes claires.
Ponctuel, planifié à l'avanceBudget & facturation
Un devis lisible sépare ce qui est forfaitaire de ce qui est itératif et de ce qui est récurrent. Les mélanger, c'est le moyen le plus sûr de créer un désaccord au troisième mois.
Un montant fixe et connu. Il vous appartient : les livrables restent utilisables même si vous décidez de ne pas poursuivre.
Un coût par sprint identique et prévisible. Vous décidez à la fin de chacun si le suivant est engagé.
Hébergement, mises à jour et heures d'évolution, séparés du projet initial.
Un travail continu, facturé au mois. Jamais présenté comme un lot du projet : ce serait mentir sur sa nature.
Aucun frais de gestion, de plateforme ni de dossier. Le prix affiché est le prix payé.
Questions fréquentes
Le cadrage verrouille le volume et le budget, pas le détail. Si, au sprint 3, une fonctionnalité prévue s'avère inutile et qu'une autre devient prioritaire, l'échange se fait — à volume équivalent, sans avenant. Ce qui est fixé, c'est le combien ; ce qui reste ouvert, c'est le quoi exactement.
C'est chiffré séparément et vous décidez. Deux options : l'intégrer en repoussant d'autant la livraison, ou le placer dans un sprint ultérieur après la mise en ligne. Aucune décision de ce type n'est prise sans vous.
Comptez environ deux heures par sprint : la démonstration, le point d'avancement et les validations. C'est peu, mais c'est incompressible — un projet où le client n'est jamais disponible prend systématiquement du retard.
Oui, à la fin de n'importe quel sprint. Vous repartez avec ce qui a été livré et développé jusque-là, code et accès compris. Aucune clause de durée minimale n'est imposée.
Elle s'allège. Sur un site vitrine de cinq pages, le cadrage tient en quelques jours, la réalisation en deux sprints et les rituels se réduisent à une démonstration et une validation. Le principe demeure : cadre ferme, itérations visibles, recette planifiée.
Un espace de suivi partagé recense le backlog, l'état de chaque tâche et les décisions prises. Vous y accédez en permanence, sans avoir à demander où en est le projet.
Le premier échange, gratuit et sans engagement, sert précisément à cela : estimer le nombre de sprints, la durée du cadrage et l'ordre de grandeur budgétaire.
