Quatre-vingt-dix jours, est-ce reproductible sur n’importe quel projet ?

Non. Ce rythme suppose un périmètre initial étroit, un décideur unique disponible chaque semaine, et l’absence de dépendance externe bloquante. Quand une contrainte réglementaire ou un partenaire tiers entre en jeu, le délai est fixé par eux, pas par la vitesse d’écriture du code.

Le code écrit avec de l’IA est-il de moins bonne qualité ?

La qualité dépend de la revue, pas de l’outil qui a produit le premier jet. Un code généré puis relu, testé et corrigé vaut un code écrit à la main puis relu, testé et corrigé. Le risque réel est d’accepter sans relire, et il se traite par le processus.

Pourquoi facturer au forfait plutôt qu’à l’heure ?

Parce que la facturation horaire pénalise la rapidité et récompense l’étirement. Un forfait par périmètre donne au client un budget connu à l’avance et nous donne intérêt à livrer vite et juste.

Que se passe-t-il si le périmètre change en cours de route ?

Le périmètre est la variable d’ajustement, pas la date. Un ajout implique un arbitrage explicite sur ce qui sort en contrepartie, décidé lors du point hebdomadaire. Un palier supplémentaire fait l’objet d’un nouveau forfait.

Livrer un produit en 90 jours : ce que l’IA change vraiment

Nous annonçons une plateforme d’investissement livrée en environ quatre-vingt-dix jours, pour à peu près cent six mille lignes de code. Le chiffre impressionne, et c’est justement pour ça qu’il mérite d’être découpé. Voici ce qu’il recouvre, ce que l’IA accélère réellement, et ce qu’elle n’accélère pas du tout.

Ce que veut dire « cent six mille lignes »

Une ligne de code n’est pas une unité de valeur. Ce volume comprend les migrations de base de données, les tests, les fichiers de configuration et le code généré par les outils. Un développeur peut multiplier ce chiffre par trois en changeant de style de formatage.

Ce que le chiffre dit vraiment, c’est l’ampleur du périmètre couvert : authentification et gestion des rôles, parcours d’entrée en relation avec vérification d’identité, signature électronique, tableaux de bord, back-office d’administration, envois transactionnels, et l’infrastructure de déploiement autour. Sur un rythme classique, ce périmètre se planifie sur six à neuf mois.

Autre précision utile, parce que l’honnêteté sur les chiffres fait partie du travail : un de nos autres projets affiche un volume comparable, mais il s’agit pour l’essentiel d’un thème e-commerce du marché, dont seule une petite part a été écrite par nous. Nous ne comptons pas ces lignes-là dans nos réalisations.

Ce que l’IA accélère vraiment

Le premier jet

Écrire une couche d’accès aux données, un formulaire complet avec sa validation, une suite de tests d’intégration : c’est du travail connu, répétitif, et c’est là que le gain est le plus net. Ce qui prenait une journée prend une heure ou deux.

La traversée de l’inconnu

Intégrer une API que l’on découvre demandait des heures de lecture de documentation. Le gain vient moins de la génération de code que de la réduction du temps passé à comprendre.

Le travail ingrat

Migrations, renommages à grande échelle, mise à niveau de dépendances, rédaction des tests manquants. Ce sont des tâches à faible densité de décision et à fort volume, exactement le profil où l’assistance est la plus rentable.

Ce que l’IA n’accélère pas

C’est la partie qu’on lit rarement, et c’est elle qui détermine si un projet tient ses délais.

Décider quoi construire. Aucune assistance ne vous dira quel produit mérite d’exister. Cette décision reste le goulet d’étranglement principal.
Obtenir les réponses métier. Si le délai de réponse à une question fonctionnelle est de cinq jours, le projet avance au rythme de cinq jours par question, quelle que soit la vitesse d’écriture du code.
Les dépendances externes. Un compte bancaire, un accès à une API réglementée, une validation juridique : ces délais sont incompressibles et sont la première cause de retard réelle.
La qualité des données existantes. Reprendre un historique incohérent demande un travail d’analyse que rien ne compresse.
La confiance. Un logiciel qui manipule de l’argent ou des données personnelles exige des vérifications qui prennent le temps qu’elles prennent.

Formulé autrement : l’IA a déplacé le goulet d’étranglement de l’écriture vers la décision. C’est une bonne nouvelle, à condition d’organiser le projet en conséquence.

La méthode qui rend le rythme tenable

Un forfait, jamais un compteur horaire

Facturer à l’heure quand on écrit vite revient à se pénaliser d’être efficace, et pousse à étirer les missions. Un forfait par périmètre aligne les intérêts : nous avons intérêt à livrer vite et juste, vous avez un budget connu à l’avance.

Un point par semaine, avec quelque chose qui tourne

Pas de diapositives, pas de comité mensuel. Chaque semaine, une version déployée que vous pouvez utiliser. C’est ce qui permet de corriger une erreur de cadrage à la deuxième semaine plutôt qu’au quatrième mois.

Le périmètre se négocie, la date ne bouge pas

Quand un imprévu survient, la variable d’ajustement est la liste des fonctionnalités, pas la date de mise en production. Cela impose de trier en continu, ce qui est précisément l’exercice qui manque à la plupart des projets qui dérapent.

La visibilité est intégrée, pas ajoutée après

Le rendu côté serveur, la structure des URL, les données structurées et l’accessibilité aux robots se décident au moment de l’architecture. Les rajouter après coup coûte plusieurs fois le prix, et c’est le cas de figure que nous rencontrons le plus souvent chez des clients qui arrivent avec un produit déjà construit. Le détail de ces choix est dans notre guide du GEO.

Les conditions pour que ça tienne

Trois conditions, et elles portent toutes sur le client plutôt que sur le prestataire.

Un décideur unique, disponible une heure par semaine. Pas un comité. Une personne qui peut trancher.
Un périmètre initial étroit. Un produit qui fait une chose et la fait entièrement, plutôt qu’une plateforme complète à moitié finie.
L’acceptation de jeter. Une part du travail des premières semaines sert à apprendre, et sera remplacée. C’est le prix de la vitesse, et c’est moins cher que de construire longtemps la mauvaise chose.

Sans ces trois conditions, le rythme de quatre-vingt-dix jours n’est pas atteignable, et il serait malhonnête de le promettre.

Cette façon de travailler porte un nom : c’est le métier de Forward Deployed Engineer. Nos formules et leurs prix sont détaillés sur la page d’accueil.

Comment se répartissent réellement les quatre-vingt-dix jours

La répartition surprend souvent, parce qu’elle ne ressemble pas à la courbe qu’on imagine. Voici l’ordre de grandeur constaté sur la plateforme d’investissement, en semaines.

Période	Ce qui s’y passe	Part du temps
Semaines 1 à 2	Comprendre le métier, poser l’architecture, la première mise en ligne	15 %
Semaines 3 à 7	Le cœur fonctionnel, à un rythme soutenu	35 %
Semaines 8 à 10	Les intégrations externes, et l’attente qui va avec	20 %
Semaines 11 à 13	Les cas limites, la sécurité, les vérifications, la mise en production	30 %

Deux enseignements. D’abord, le cœur fonctionnel, la partie que tout le monde imagine longue, occupe environ un tiers du temps. Ensuite, le dernier tiers, celui qui traite les cas limites et la sécurité, est aussi long que le cœur, et c’est lui qu’on sous-estime systématiquement dans les devis.

Le pic de risque ne se situe pas au démarrage mais autour de la semaine huit, au moment des dépendances externes. C’est là qu’un accès qui n’arrive pas fait glisser toute la suite, sans qu’aucune ligne de code n’y puisse quoi que ce soit.

Ce que nous avons jeté

Sur ce projet, trois travaux ont été écrits puis remplacés. Les mentionner n’est pas de la modestie mal placée : c’est le mécanisme même du modèle, et le taux de rebut fait partie du coût annoncé.

Un premier parcours d’entrée en relation, conçu à partir de ce que le métier décrivait. La confrontation aux premiers utilisateurs a montré que deux étapes sur cinq n’avaient pas lieu d’exister. Trois jours de travail, remplacés en une journée.
Un tableau de bord complet, dont trois indicateurs sur huit n’ont jamais été consultés. Nous les avons retirés plutôt que de les maintenir.
Une couche d’abstraction construite pour supporter plusieurs prestataires de signature, alors qu’un seul a été retenu. Cas typique de généralisation prématurée, et le seul des trois qui aurait pu être évité.

Rapporté à l’ensemble, ce rebut représente environ une semaine sur treize. C’est le prix de la vitesse, et il reste très inférieur au coût de plusieurs mois passés à construire la mauvaise chose avec méthode.

Ce que le forfait implique de notre côté

Annoncer un prix ferme sur un périmètre partiellement connu suppose d’accepter trois contraintes, qu’il est honnête d’exposer.

Nous refusons certains projets. Quand la demande arrive sous forme d’un cahier des charges figé de quarante pages, le modèle ne s’applique pas et un prestataire classique fera mieux. Nous le disons plutôt que de prendre la mission.

Nous provisionnons l’imprévu. Un forfait qui ne prévoit pas de marge est un forfait qu’on renégocie, ce qui revient à facturer en régie avec une étape de conflit en plus. La marge est incluse dès le départ, et c’est aussi pour ça que le prix affiché n’est pas le plus bas du marché.

Nous arbitrons en continu. À périmètre constant et date fixe, chaque ajout implique un retrait. Cet arbitrage se fait au point hebdomadaire, avec le décideur, jamais en fin de projet.

Ce que nous ne promettons pas

Un produit livré en quatre-vingt-dix jours n’est pas un produit terminé. C’est un produit en production, utilisé, dont la suite se décide sur des usages réels plutôt que sur des hypothèses. La différence est considérable et rarement dite.

Nous ne promettons pas non plus que le rythme se transpose à un projet où une autorité de contrôle, un partenaire bancaire ou un service juridique impose son propre calendrier. Dans ces cas, la contrainte n’est plus la vitesse d’écriture du logiciel, et prétendre le contraire serait vous vendre un délai que nous ne tenons pas.

À retenir

Une ligne de code n’est pas une unité de valeur. Ce que mesure un volume de code, c’est l’ampleur du périmètre couvert.
L’IA accélère le premier jet, la découverte d’une API inconnue et le travail répétitif. Elle n’accélère ni la décision, ni les dépendances externes, ni la qualité des données existantes.
Le goulet d’étranglement s’est déplacé de l’écriture vers la décision. C’est le projet qu’il faut réorganiser, pas seulement l’outillage.
Le périmètre est la variable d’ajustement, jamais la date de mise en production.
Trois conditions côté client : un décideur unique disponible une heure par semaine, un périmètre initial étroit, et l’acceptation de jeter une partie du travail des premières semaines.