Le "comment ça marche" est souvent flou chez les prestataires. On parle de méthode agile, de sprints, de tickets, mais rarement de ce qui se passe vraiment entre votre première demande et un outil qui tourne. On a découpé notre chaîne de production en six étapes. Voici ce qui se passe à chacune, sans filtre.
Étape 1 : le récit
Une visio d'une heure, en général deux. Vous nous racontez votre besoin avec vos mots. Pas de template, pas de questionnaire en 84 questions. Notre chef de projet et un designer écoutent, posent des questions, prennent des notes.
À la fin de l'appel, nous savons en gros : qui utilisera l'application, pour faire quoi, dans quel contexte, avec quelles contraintes. C'est suffisant pour passer à l'étape suivante.
Étape 2 : la clarification
Notre agent rédacteur de specs ingère la transcription de l'appel et produit un premier document structuré : personas, parcours principaux, cas limites identifiés, hypothèses à valider. Ce document fait 5 à 10 pages, jamais plus.
Notre product designer reprend ce premier jet. Il comble les angles morts, reformule, ajoute ses propres questions. On vous le partage en moins de 48 h.
On enchaîne avec un appel de validation : ce qu'on a compris correspond-il à votre besoin ? Souvent, le simple fait de relire ses propres mots reformulés fait émerger des choses qu'on n'aurait pas dites spontanément. C'est le but.
Étape 3 : maquettes et prototypes
Une fois les specs validées, notre agent designer produit des maquettes basse fidélité de tous les écrans clés. Notre designer reprend, retravaille les écrans structurants, affûte le ton visuel.
On vous présente un prototype cliquable en moins d'une semaine après l'appel initial. Vous testez vous-même, vous le partagez en interne, vous nous remontez ce qui ne va pas.
Étape 4 : Build
C'est le cœur de l'atelier. Nos agents développeurs produisent le code couche par couche, sous la supervision d'un de nos ingénieurs par projet. L'ingénieur prend les décisions structurantes (architecture, choix de bibliothèques, sécurité), relit chaque pull request, et garantit la qualité.
Vous, vous voyez le produit prendre forme. À chaque jalon (en général tous les 3 à 5 jours), on déploie en pré-production une version utilisable. Vous testez, vous remontez, on ajuste.
Étape 5 : recette
Quand l'application est complète, on entre en recette formelle. Vous testez l'ensemble avec vos propres données, dans votre contexte. Notre relecteur IA tourne en parallèle : il rejoue des centaines de scénarios automatiquement pour traquer les régressions.
On itère jusqu'à ce que la liste de retours soit vide. En moyenne, deux ou trois cycles suffisent.
Étape 6 : mise en production
Cf. notre récit détaillé d'une mise en ligne pour le déroulé heure par heure. L'idée : que rien ne soit improvisé, et que vos premiers utilisateurs ne ressentent rien d'autre que "tiens, la nouvelle application est là, et elle marche".
Combien de temps en tout ?
Pour un outil métier de taille moyenne : 4 à 6 semaines de bout en bout. Pour un prototype destiné à tester une idée : 1 à 2 semaines. Pour une application complexe avec intégrations multiples : 8 à 12 semaines.
Ces durées ne sont pas négociables à la baisse. Si quelqu'un vous promet le même périmètre en deux fois moins de temps, soit il vous ment, soit il livrera une application bancale. Aller vite, oui ; sacrifier la qualité, non.
Ce qu'on ne montre jamais aux clients
Les ratés. Les pull requests refusées par le relecteur. Les choix d'architecture qu'on a abandonnés après deux jours de travail parce qu'on avait mal anticipé une contrainte. Ces ratés font partie du métier, ils sont absorbés dans le forfait. Vous n'en voyez que les bénéfices : une application qui marche, livrée dans les temps.