De la première commit au produit en ligne en 48 heures

21 novembre 2025, 9h14

C’est à ce moment-là que nous avons poussé le premier commit. Un projet vide. Une toile vierge. D’ici le 23 novembre à minuit, nous avions un produit en ligne avec un domaine personnalisé, servant de vrais utilisateurs.

Ce n’est pas une histoire de raccourcis ou de logiciels défectueux. C’est ce qui se passe quand vous savez exactement ce que vous construisez et refusez de perdre du temps sur autre chose.

Ce qui a été lancé en 48 heures

Voici ce qui était en ligne à la fin du deuxième jour :

Une interface de chat AI en temps réel. Pas un wrapper autour d’une API. Un véritable système de chat avec gestion de session, historique des messages et réponses en streaming. Les utilisateurs pouvaient avoir des conversations avec des agents AI qui se souvenaient réellement du contexte.

Un système de fichiers virtuel. Les utilisateurs pouvaient créer des dossiers, télécharger des fichiers, les renommer, les organiser en espaces de travail. L’AI pouvait lire et écrire dans ces fichiers pendant les conversations. Pas une démo jouet — un vrai système de fichiers soutenu par MongoDB.

Espaces de travail avec changement d’agent. Différents espaces de travail pouvaient utiliser différents agents AI avec différentes capacités. Un utilisateur pouvait avoir un espace de travail pour le codage, un espace pour l’écriture et un espace pour la recherche — chacun avec son propre contexte et ses fichiers.

Authentification utilisateur et synchronisation. Connecté à notre système d’auth via RabbitMQ. Les utilisateurs se connectaient et leurs données étaient là. Sur tous les appareils. Immédiatement.

Génération d’images. L’AI pouvait générer des images pendant les conversations. Pas seulement des réponses textuelles — une véritable sortie visuelle.

Modèles. Points de départ préconstruits pour que les utilisateurs ne se retrouvent pas face à un écran vide lors de leur première visite.

Pipeline de déploiement. Dockerisé, déployé, fonctionnant sur un domaine personnalisé avec une configuration d’environnement adéquate.

Les décisions qui ont rendu cela possible

Une telle rapidité ne vient pas de travailler 48 heures d’affilée (bien qu’il y ait eu beaucoup de cela). Cela vient des décisions que vous prenez avant d’écrire la première ligne de code.

Décision 1 : MongoDB plutôt que Mongoose. Nous avons commencé avec Mongoose pendant environ quatre heures. Puis nous sommes passés aux pilotes MongoDB bruts. Mongoose ajoute une couche de validation de schéma qui est utile pour les grandes équipes mais qui est un pur surcoût pour une petite équipe qui connaît son modèle de données. Quatre heures “perdues” qui nous ont fait économiser des dizaines d’heures dans les semaines suivantes.

Décision 2 : Construire le serveur et le client dans un seul repo. Monorepo. Un docker-compose.yml. Une commande de déploiement. Pas de coordination entre les repos. Pas de “l’API est déployée mais le frontend ne l’est pas.” Quand vous avancez vite, réduire le nombre de choses qui peuvent se désynchroniser est plus important que la pureté organisationnelle.

Décision 3 : Déployer en production le jour deux, pas le jour vingt. Nous avons déployé avant d’être “prêts.” Le domaine était configuré, le SSL était mis en place, les variables d’environnement étaient en place — tout cela avant que la moitié des fonctionnalités ne soient construites. Pourquoi ? Parce que le déploiement est la partie qui vous surprend. Mieux vaut découvrir ces surprises le jour deux avec trois fonctionnalités que le jour vingt avec trente.

Ce que nous n’avons pas construit

Tout aussi important que ce que nous avons expédié est ce que nous avons délibérément laissé de côté :

• Pas de panneau d’administration. Nous avons utilisé MongoDB Compass directement.
• Pas de système de design personnalisé. Nous avons utilisé des valeurs par défaut propres et itéré plus tard.
• Pas d’analytique. Nous avons regardé les journaux du serveur.
• Pas de tests automatisés. (Cela est arrivé le jour trois.)
• Pas de documentation. Le code était la documentation.

Chacune de ces décisions aurait été la chose “responsable” à construire. Chacune aurait coûté une journée. Et aucune d’entre elles ne nous aurait appris ce que nous avons appris en mettant le produit devant de vrais utilisateurs le jour deux.

La leçon

Il existe une version de cette histoire où nous passons deux semaines sur des diagrammes d’architecture. Où nous débattons sur des schémas de base de données dans un Google Doc. Où nous mettons en place un véritable pipeline CI/CD avant d’écrire du code d’application.

Cette version de l’histoire se termine avec un beau plan et aucun produit.

La version qui s’est réellement produite s’est terminée avec un produit fonctionnel et une longue liste de choses à améliorer. Nous choisirons cet échange à chaque fois.

Quarante-huit heures. Premier commit à produit en ligne. Pas parce que nous sommes des génies. Parce que nous avons pris des décisions rapidement, expédié plus vite et corrigé les choses en production comme tout le monde le fait réellement — mais que peu l’admettent.

Le produit que vous voyez aujourd’hui, 84 jours et 632 commits plus tard, a commencé juste là. En 48 heures.