La plupart des agences vous vendent une vision en réunion. Un deck soigné, des références impressionnantes, tous les bons mots sur l'agilité et le design centré utilisateur.
Puis vous signez. Et silence.
Des semaines passent. Vous envoyez un email de relance. Vous obtenez une mise à jour vague. Finalement, vous voyez une démo qui ne correspond pas à ce que vous aviez discuté. À ce stade, vous avez déjà payé 40 % et vous vous demandez ce qui s'est passé.
On entend cette histoire de presque chaque client qui vient nous voir après un engagement raté. Le problème est rarement technique. C'est le processus. L'agence n'en avait pas — ou n'a pas suivi celui qu'elle avait promis.
Cet article est la réponse qu'on donne à chaque prospect qui demande : « Concrètement, que se passe-t-il après la signature ? »
Phase 1 : Kickoff et verrouillage du périmètre
Avant d'écrire une seule ligne de code, on verrouille le périmètre. Pas avec une proposition vague — avec un document que les deux parties valident.
Le kickoff n'est pas une discussion informelle. C'est une session de travail structurée où on transforme le brief du client en quelque chose de constructible. Si vous n'avez pas encore écrit de brief, on a publié un guide sur comment en rédiger un qui aide vraiment. Ça signifie des user stories avec des critères d'acceptation, une liste de fonctionnalités priorisée, et — tout aussi important — une section explicite « hors périmètre ».
Cette dernière partie compte plus qu'on ne le pense. Le scope creep ne commence pas par de grosses demandes. Il commence par des hypothèses. « Je pensais que le tableau de bord inclurait aussi les exports. » « Je croyais que la version mobile était comprise. » Si ce n'est pas écrit et validé, ça n'existe pas.
On dit non tôt pour ne pas avoir à dire « ça coûtera plus cher » plus tard. Les clients apprécient ça plus qu'ils ne s'y attendent.
Le livrable de cette phase : un document de spécifications cadré avec priorités, délais et limites. Le client le valide avant qu'on avance.
Phase 2 : Design et validation
On conçoit avant de construire. Ça semble évident, mais vous seriez surpris du nombre de projets qui passent directement du brief au code.
Notre processus : wireframes d'abord, puis design UI. Le client voit et valide le flux — chaque écran, chaque interaction — avant qu'on touche un éditeur de code. Ce n'est pas une question d'esthétique. C'est une question de détecter les malentendus tôt, quand ils coûtent des heures à corriger au lieu de semaines.
« Validation » ici a un sens précis. Ça veut dire que le client a examiné chaque écran, confirmé que le flux correspond à ses attentes, et signé. Pas un pouce en l'air sur Slack. Une confirmation documentée qui dit « oui, construisez ça. »
Cette phase élimine le plus grand risque des projets logiciels : construire la bonne chose de la mauvaise façon, ou la mauvaise chose de la bonne façon.
Phase 3 : Construction en sprints, démo toutes les deux semaines
On travaille en cycles de deux semaines. À la fin de chaque cycle, le client reçoit une démo live de ce qui a été construit — du logiciel fonctionnel, pas des slides.
C'est non négociable chez nous. On ne disparaît jamais pendant un mois pour revenir avec une surprise. Toutes les deux semaines, le client voit la progression, donne son feedback, et confirme qu'on est sur la bonne voie.
Que se passe-t-il quand le client veut changer quelque chose en cours de sprint ? Ça arrive sur chaque projet, et c'est normal — à condition que ce soit géré. On évalue le changement : est-ce que ça rentre dans le sprint actuel ? Est-ce que ça remplace autre chose ? Est-ce que ça décale le planning ? On donne le compromis au client, il décide, et on documente. Pas de drame, pas de coûts cachés. La façon dont on gère l'aspect financier dépend du modèle de tarification — on a écrit un article séparé qui explique comment chaque modèle gère les changements de périmètre différemment.
Le rythme compte. Les cycles de deux semaines créent de la responsabilité des deux côtés. On livre régulièrement, et le client reste impliqué. Les projets qui sombrent — quand le client disparaît pendant un mois puis réapparaît avec de nouvelles priorités — sont ceux qui échouent. La structure en sprints empêche ça.
Phase 4 : Tests, transmission et mise en production
Avant que quoi que ce soit arrive en production, ça passe par la QA. On teste sur un environnement de staging — un miroir de la production — où le client peut aussi tester et signaler des problèmes.
Le déploiement n'est pas un événement stressant pour nous. On utilise des pipelines de déploiement automatisés. Du staging à la production, c'est un processus contrôlé, pas une prière.
Ce que le client reçoit à la transmission, ce n'est pas juste un accès à une application en ligne. C'est un package : le code source complet dans un dépôt Git, une documentation technique couvrant l'architecture, la configuration et les décisions clés, les identifiants admin et la configuration de l'environnement, et une session de formation pour que l'équipe du client puisse réellement utiliser et gérer ce qu'on a construit.
« Terminé » signifie que le client peut faire fonctionner le logiciel sans nous. S'il a besoin de nous pour des développements futurs, tant mieux. Mais il n'est jamais prisonnier. Le code est le sien, la documentation est claire, et n'importe quel développeur compétent peut reprendre le projet. Ce qui vient après — hébergement, mises à jour de sécurité, développement continu — est une conversation séparée qu'on a avant le lancement, pas après. On a écrit sur ce qu'implique réellement la maintenance post-lancement et combien elle coûte.
Ce qu'on ne fait pas
Ce ne sont pas des critiques de l'industrie. Ce sont des engagements qu'on prend avec chaque client :
On ne commence pas sans un périmètre signé. On ne saute pas la phase de design. On ne disparaît pas entre les démos. On ne livre pas du code non documenté. On ne prend pas le code en otage. On ne dit pas « c'était inclus » quand ce n'était pas écrit.
Chacun de ces points vient d'un pattern qu'on a vu dans des projets échoués que des clients nous ont apportés pour sauvetage. On a construit notre processus spécifiquement pour les éviter.
Ce que ça signifie pour vous
Si vous avez déjà vécu un engagement logiciel raté, la plupart de ce que j'ai décrit vous semblera relever du bon sens. C'est exactement ça. Une bonne livraison, ce n'est pas de la magie — c'est de la discipline appliquée de manière constante.
Si c'est votre premier projet logiciel sur mesure, utilisez cet article comme checklist. Demandez à votre agence : à quoi ressemble votre processus de livraison ? Si la réponse est vague, ça vous dit quelque chose. On a compilé la liste complète des questions à poser avant de signer.
On a déjà écrit sur pourquoi on construit tout avec Laravel — notre choix de stack fait partie de notre capacité à livrer de manière fiable. On a aussi couvert combien de temps prennent les projets et quand construire sur mesure est la bonne décision. Mais la stack n'est qu'un outil. C'est le processus qui fait ou défait un projet.
Vous avez un projet en tête — ou un projet à sauver ? Parlons-en →