Comment nous livrons des projets 10× plus vite avec une implémentation assistée par LLM — sans sacrifier la qualité.
Le projet en cascade est mort.
Douze semaines de phase de conception, six semaines de spécification, puis un semestre de développement à l'issue duquel presque plus personne ne sait pourquoi une exigence figurait à l'origine dans le cahier des charges. Quiconque a acheté du logiciel ainsi ces vingt dernières années connaît le schéma — et le risque que le résultat passe à côté du marché.
Avec une implémentation assistée par LLM, nous livrons aujourd'hui la première version fonctionnelle en jours plutôt qu'en mois. Pas un prototype à jeter, mais une base de code qui continue de tourner en production. Cela ne déplace pas seulement les calendriers, cela change la manière dont les décisions sont prises.
Car lorsqu'une version fonctionnelle est sur la table au bout de trois jours plutôt que de trois mois, on ne discute plus sur des maquettes — on clique à travers un vrai système et l'on remarque aussitôt ce qui manque. Des exigences qui semblaient plausibles sur le papier se révèlent en minutes, sur le produit en marche, superflues ou mal pensées.
D'où vient le facteur 10.
Le gain de vitesse ne vient pas d'une frappe plus rapide, mais de la disparition de la friction. Boilerplate, modèles de données, connexions d'API, échafaudages de tests — tout ce qui relevait autrefois de jours de travail laborieux, un modèle le génère en minutes. Nos développeurs passent leur temps là où le discernement compte : architecture, cas limites, intégration.
Comparaison typique tirée de nos projets : un portail client avec authentification, rôles, trois systèmes connectés et reporting demandait autrefois environ quatre mois jusqu'au lancement en production. Avec un build assisté par LLM, les deux premières semaines ont suffi pour un MVP utilisable, le déploiement complet après un peu plus de six semaines.
Point essentiel : le modèle écrit du code, l'humain en répond. Chaque ligne générée passe par une relecture, des tests et nos gates de sécurité. Personne ne merge sans avoir lu.
Le goulot d'étranglement se déplace ainsi de la production vers la décision. Ce n'est plus la question « combien de temps cela prend-il ? » qui fixe le rythme, mais « que voulons-nous construire exactement ? » — et c'est précisément à cette question que l'on répond plus vite et plus honnêtement sur un système en marche que dans n'importe quel atelier.
Pourquoi la qualité monte, et ne baisse pas.
Le réflexe est compréhensible : rapide rime avec bâclé. En pratique, c'est l'inverse. Parce que la couverture de tests, le linting et la documentation ne représentent presque plus de surcoût, ils sont créés dès le départ — au lieu d'être sacrifiés à la fin, quand le budget se fait rare.
Des itérations plus rapides signifient aussi que les fausses hypothèses sautent aux yeux tôt. Une erreur de conception qui, dans un projet classique, ne devient visible qu'au test de recette après six mois, nous saute aux yeux dès la première semaine — quand la correction coûte encore des heures plutôt que des semaines.
Nous le mesurons : la densité de défauts et la part de reprise après lancement ne sont pas plus élevées dans les projets construits rapidement, mais plus faibles que dans l'approche classique.
Là où le facteur 10 ne s'applique pas.
L'honnêteté en fait partie : tous les projets ne s'accélèrent pas d'un facteur 10. Là où la complexité ne réside pas dans le code, mais dans la coordination, les validations réglementaires ou la migration de systèmes hérités, le modèle n'est qu'une brique parmi d'autres. L'implémentation n'y a jamais été le goulot d'étranglement.
De même, pour une logique fortement spécifique au domaine — tarification actuarielle d'assurance, pilotage critique pour la sécurité —, la part de travail humain reste élevée, car chaque erreur y coûte cher et le modèle, sans expertise métier profonde, ne juge pas de façon fiable.
Nous le communiquons ouvertement, au lieu de promettre partout le même facteur. Le gain honnête se situe en moyenne plutôt autour d'un facteur 3 à 5 sur l'ensemble du projet — et, pour le build standard où la friction domine, précisément autour de 10.
Ce que cela signifie pour nos clients.
Newroom est un exécutant, pas un conseil. La vitesse n'est pas pour nous une fin en soi, mais le socle qui permet de construire un produit, de le déployer et de l'exploiter — et de le faire évoluer après le lancement, au lieu de le figer.
Pour le client, le risque se déplace : au lieu de parier un gros budget contre un cahier des charges, il voit de la substance au bout de quelques jours et décide sur la base de ce qui fonctionne. Une mauvaise décision ne coûte plus un demi-projet, mais une itération.
C'est là la véritable révolution — pas la vitesse, mais la sécurité qu'elle crée. Qui voit en jours au lieu de croire en mois prend de meilleures décisions.