Livrer en production sans se planter : la méthode Build & Run

Beaucoup d'entreprises ont vécu ça : un prestataire livre "le système", et six mois plus tard, personne dans l'équipe ne sait comment il fonctionne, où regarder quand ça plante, ni comment reprendre la main si la relation s'arrête. Ce n'est pas de la malveillance, c'est souvent juste une mauvaise méthode de livraison. Chez Lucid-Lab, on a formalisé ce qu'on appelle le Build & Run : un ensemble de livrables non-négociables qui font qu'un système autonome en production reste sous contrôle, même sans nous.

Ce que "livrer en production" veut vraiment dire

Livrer un système fonctionnel, ce n'est pas envoyer un lien vers une démo ou pousser du code sur un serveur. C'est transmettre quelque chose que votre équipe peut opérer, surveiller, faire évoluer et, si nécessaire, reprendre en mains sans vous.

Cette distinction est fondamentale pour une PME. Vous n'avez pas d'équipe tech de 20 personnes. Vous avez peut-être un dev en interne, un ops, ou rien de tout ça. Ce que vous recevez doit donc être pensé pour être compris par un humain qui n'était pas là pendant le build.

La méthode Build & Run repose sur un principe simple : chaque projet produit des artefacts tangibles, pas seulement du code qui tourne. Ces artefacts, on va les détailler un par un.

Les builds incrémentiels : livrer souvent, livrer ce qui marche

Pas de big bang, pas de surprises

Un projet livré d'un seul coup après trois mois de développement, c'est une recette pour les mauvaises surprises. Les besoins ont changé, les hypothèses initiales étaient partiellement fausses, et le code n'a jamais été confronté à la réalité de vos données.

Chez Lucid-Lab, on structure chaque projet en incréments testables. Concrètement : toutes les deux semaines environ, vous avez quelque chose qui tourne sur un environnement de staging, avec de vraies données ou des données représentatives. Vous pouvez cliquer, casser, valider.

Sur le projet Universal (automatisation de la lead gen pour un acteur de la distribution), on a livré en quatre incréments : d'abord l'extraction et la qualification des leads, ensuite l'enrichissement, puis le scoring, enfin l'orchestration complète. À chaque étape, le client pouvait décider d'aller plus loin ou de pivoter. Il n'a pas attendu le sprint 8 pour découvrir que le scoring ne correspondait pas à sa réalité commerciale.

Des tests qui documentent le comportement

Chaque incrément livré vient avec une couverture de tests. Pas pour vous impressionner avec des métriques de couverture de code, mais parce que les tests servent à deux choses concrètes :

• Ils empêchent les régressions quand on ajoute une feature
• Ils documentent le comportement attendu du système pour quelqu'un qui reprend le projet

Si demain vous faites appel à un autre prestataire pour faire évoluer le système, les tests lui disent exactement ce qui doit continuer à fonctionner. C'est une forme de documentation vivante.

Les livrables concrets : ce que vous recevez à chaque projet

Le repo GitHub : votre code, votre propriété

Le premier livrable est le plus basique, et pourtant le plus souvent mal géré : vous êtes propriétaire du code, dès le premier commit.

Pas un accès en lecture sur notre repo. Pas une archive zip envoyée en fin de projet. Un repository GitHub dans votre organisation, avec l'historique complet des commits, les branches, les pull requests. Vous pouvez auditer, forker, transférer à n'importe quel moment.

C'est le fondement du no vendor lock-in. On reviendra sur ce point plus loin, mais retenez ça : si vous ne pouvez pas accéder à votre code sans passer par votre prestataire, vous n'êtes pas propriétaire de votre système.

Le schéma de base de données : lisible et versionné

Pour les projets qui impliquent de la donnée structurée (ce qui est souvent le cas), vous recevez le schéma complet de la base de données, documenté et versionné.

Sur Turismo, un projet de scaling d'une plateforme de réservation, la base de données est au coeur de tout : profils voyageurs, disponibilités, règles de pricing, historique de transactions. Le schéma livré n'est pas juste un export SQL. C'est un document annoté, avec les relations entre tables, les contraintes, les index et la logique métier qui justifie certains choix de modélisation.

Pourquoi c'est non-négociable : si dans deux ans vous voulez migrer vers un autre outil, intégrer un nouveau système ou simplement comprendre pourquoi une requête est lente, vous avez besoin de ce document. Sans lui, vous repartez de zéro.

On travaille principalement avec Supabase pour les projets qui nécessitent une base de données relationnelle avec une couche API. Pas parce que c'est à la mode, mais parce que Supabase est open source, auto-hébergeable, et que le schéma que vous recevez peut être déployé sur n'importe quel PostgreSQL si vous décidez de partir.

Les logs structurés : savoir ce qui se passe, vraiment

Un système en production sans logs structurés, c'est une voiture sans tableau de bord. Vous savancez, peut-être, mais vous ne savez pas à quelle vitesse, si le moteur chauffe, ni combien d'essence il reste.

Les logs structurés, c'est la pratique de produire des événements formatés (généralement en JSON) plutôt que des lignes de texte libres. Concrètement, au lieu d'un message "Erreur lors du traitement du lead 4892", vous avez un événement avec le timestamp précis, l'identifiant du lead, le module qui a planté, le contexte d'exécution et le message d'erreur. Ce format est lisible par un humain et interrogeable par une machine.

Sur le projet Périscope (un système de monitoring opérationnel pour un acteur de la santé), les logs structurés ont permis de détecter un pattern anormal en quelques minutes : un type de capteur envoyait des valeurs aberrantes de manière intermittente, uniquement entre 2h et 4h du matin. Sans logs structurés, ce problème aurait mis des jours à être identifié.

Les alertes : être prévenu avant le client

Les alertes, c'est la couche au-dessus des logs. Plutôt que d'aller chercher l'information, l'information vient à vous quand quelque chose sort de la normale.

Sur chaque projet, on configure un ensemble d'alertes adaptées aux risques métier du système :

• Taux d'erreur qui dépasse un seuil
• Temps de traitement qui s'emballe
• Volume de données qui chute anormalement (souvent signe d'un problème en amont)
• Absence de signaux là où on en attend

Ces alertes arrivent dans le canal que vous utilisez déjà : Slack, email, webhook vers votre outil de gestion. Pas question d'apprendre un nouveau dashboard pour savoir si votre système tourne.

Le principe est simple : vous ne devez jamais apprendre qu'un problème existe parce qu'un utilisateur final vous l'a signalé.

Le runbook : opérer sans nous appeler

Ce qu'est un runbook, vraiment

Un runbook est un document opérationnel qui répond à la question : "Que faire quand X se produit ?"

Ce n'est pas de la documentation technique exhaustive. C'est un guide de première intervention, écrit pour quelqu'un qui n'est pas développeur mais qui est responsable du système. Il couvre les situations les plus probables et les plus critiques.

Structure type d'un runbook Lucid-Lab :

Pourquoi c'est souvent la chose la plus négligée

La plupart des prestataires ne livrent pas de runbook parce que c'est du travail non facturable directement et que ça demande de penser à l'opération, pas seulement au développement.

Chez Lucid-Lab, c'est non-négociable pour une raison simple : un système que vous ne pouvez pas opérer sans nous, c'est un système qui vous crée une dépendance. Et la dépendance, c'est exactement ce qu'on essaie d'éviter.

Le no vendor lock-in : une posture, pas une feature

Le no vendor lock-in traverse tous les livrables décrits ci-dessus. C'est une posture de conception, pas une option qu'on coche.

Concrètement, ça se traduit par :

• Des choix d'outils open source ou avec des alternatives documentées
• Un code que vous possédez et que n'importe quel dev peut reprendre
• Des données dans des formats standards (pas dans des bases propriétaires sans export)
• Une documentation suffisante pour qu'un autre prestataire puisse continuer le travail

Sur Turismo, on a délibérément évité un outil de scheduling propriétaire au profit d'une solution que le client peut auto-héberger. Le coût de setup était légèrement plus élevé, mais la dépendance à long terme était nulle. Le client l'a apprécié quand son contexte a changé et qu'il a dû migrer une partie de son infrastructure.

Le no vendor lock-in, c'est aussi un test de confiance. Un prestataire qui vous rend dépendant de ses outils, c'est souvent un prestataire qui n'est pas sûr de la valeur de son travail. Si le code est propre, la doc est là et les données sont accessibles, vous n'avez aucune raison de rester : vous restez parce que vous le choisissez.

Ce que tout ça change dans la pratique

La méthode Build & Run n'est pas un argument marketing. C'est une liste de livrables vérifiables. À la fin d'un projet Lucid-Lab, vous pouvez cocher :

• Repo GitHub dans votre organisation : oui ou non
• Schéma de base de données documenté : oui ou non
• Logs structurés actifs : oui ou non
• Alertes configurées et testées : oui ou non
• Runbook pour les situations critiques : oui ou non

Si l'une de ces cases n'est pas cochée, le projet n'est pas terminé. C'est aussi simple que ça.

Pour les PMEs qui évaluent un prestataire tech ou IA, ces cinq points constituent une checklist de base. Posez ces questions avant de signer. Si les réponses sont vagues, c'est un signal.

Si vous avez déjà un système en production qui ne remplit pas ces critères, il n'est pas trop tard. La plupart du temps, un audit de quelques heures suffit à identifier les lacunes et à proposer un plan pour y remédier sans tout reconstruire.