Une version testable toutes les deux semaines : comment ça se passe

Une fois les maquettes validées et le prix fixé, le développement commence. C'est souvent là que les clients décrochent dans un projet logiciel classique : le prestataire part « coder » pendant des semaines, et l'on découvre le résultat à la fin, avec ses surprises. Chez nous, vous recevez une version testable toutes les deux semaines. Je suis votre interlocuteur pendant tout le projet ; voici, concrètement, comment se passent ces quinze jours et ce que l'on attend de vous.

Pourquoi deux semaines

Le rythme n'est pas choisi au hasard. Une semaine, c'est trop court pour livrer quelque chose qui vaut la peine d'être testé. Un mois, c'est assez long pour partir dans une mauvaise direction sans s'en rendre compte. Deux semaines permettent d'ajouter une vraie fonctionnalité, de la montrer, et de corriger le tir rapidement si elle ne correspond pas à l'usage.

Ce rythme vous protège aussi. À tout moment, vous savez où en est le projet, non pas parce qu'on vous l'affirme dans un rapport, mais parce que vous pouvez cliquer dedans.

Le déroulé d'un cycle de deux semaines

Au début : ce qu'on va livrer

Nous partons de la maquette validée et nous découpons le logiciel en morceaux utilisables. Au début de chaque cycle, je vous dis ce que contiendra la prochaine version : par exemple « la création d'un devis et son envoi en PDF » ou « la liste des interventions, filtrable par technicien ». Vous savez à quoi vous attendre.

Pendant : le développement

Antoine et Jérémy développent selon le sujet : le logiciel et les interfaces d'un côté, l'infrastructure et l'IA de l'autre. Si une question se pose en cours de route (un cas particulier que la maquette ne montrait pas, une règle métier à préciser), je vous la pose tout de suite, plutôt que de laisser un développeur deviner.

À la fin : la version testable

Vous recevez un lien vers une version qui tourne réellement, sur un environnement de test séparé de vos données de production. Ce n'est plus une maquette : les boutons font ce qu'ils annoncent, les données sont enregistrées. Je vous indique ce qui est nouveau, ce qu'il faut tester en priorité, et ce qui n'est volontairement pas encore fini.

Vos retours

Vous testez, idéalement avec une ou deux personnes qui utiliseront l'outil au quotidien. Vous nous envoyez vos remarques, par écrit ou lors d'un court point en visio. Nous les classons ensemble : ce qui est un défaut à corriger, ce qui est un ajustement compris dans le projet, et ce qui est une nouvelle idée.

Ce qu'on attend de vous

La méthode ne marche que si les versions sont réellement testées. Concrètement, nous vous demandons :

• Une personne référente côté entreprise, qui centralise les retours et peut trancher une question métier.
• Une heure ou deux de test toutes les deux semaines, pas plus. Mieux vaut un test court et régulier qu'une grande séance à la fin.
• Des retours concrets. « Je ne trouve pas où ajouter un contact » est plus utile que « c'est pas intuitif ». Une capture d'écran vaut mieux qu'un long paragraphe.
• Le droit de changer d'avis, tôt. Si une fonctionnalité ne sert finalement pas, il vaut mieux le dire à la deuxième version qu'à la dixième.

Un exemple simple : sur un logiciel de suivi d'interventions, la deuxième version peut contenir la création d'une fiche et la liste des fiches, sans encore les photos ni la signature du client. Vos techniciens peuvent déjà dire si les champs sont les bons et si la saisie est assez rapide sur un téléphone. Les photos et la signature arrivent dans la version suivante, sur une base déjà validée.

Et quand une nouvelle idée arrive ?

Elle arrive toujours, et c'est bon signe : c'est la preuve que vos équipes s'approprient l'outil. Le prix a été fixé sur la maquette validée, donc nous sommes transparents sur ce qui en fait partie. Les ajustements d'un écran, d'un libellé, d'un ordre de champs : nous les intégrons. Une fonctionnalité qui n'était pas prévue : nous vous disons ce qu'elle représente, et vous décidez de l'ajouter, de la reporter à une version ultérieure, ou d'échanger avec quelque chose de moins prioritaire. Vous n'avez jamais de surprise sur la facture.

Ce que ce rythme change en fin de projet

Comme le logiciel a été testé morceau par morceau, la phase de recette finale ne découvre pas le logiciel : elle le vérifie dans son ensemble, avec vos vrais utilisateurs et des données réalistes. Les mauvaises surprises ont été traitées au fil de l'eau. Puis viennent la livraison et la formation, avec le code source et la documentation remis, comme nous l'expliquions dans notre article sur le code source à votre nom.

C'est ainsi que nous menons les projets de nos clients, qu'il s'agisse d'un logiciel métier, d'une plateforme ou d'une application. Si vous voulez savoir à quoi ressemblerait le découpage de votre projet, le rendez-vous de 30 minutes est gratuit, en visio ou au studio à Nevers.