Construire, puis faire tourner.

Il y a un moment, dans la plupart des projets d’agence, où le travail change de mains. La dernière facture est réglée, un dépôt est transféré, quelqu’un est ajouté à un compte d’hébergement, et les personnes qui ont pris chaque décision s’éloignent des conséquences de toutes. Nous avons été des deux côtés de cette passation. C’est la raison pour laquelle nous avons arrêté.

Synodic construit des produits, puis les fait tourner. Non pas comme un contrat de support greffé à la fin, mais comme l’hypothèse de départ du projet : quoi que nous livrions, c’est nous qui sommes réveillés pour ça.

Livré n’est pas la même chose qu’en marche

Un lancement, c’est un jour. Faire tourner, ce sont les dix-huit mois qui suivent, et c’est là que le coût réel d’une décision apparaît. Une dépendance cesse d’être maintenue. Le trafic arrive sous une forme que personne n’avait modélisée. Une API tierce change un format de réponse un vendredi après-midi. Rien de tout cela n’est visible dans une revue de design, et tout est visible à trois heures du matin.

Quand l’équipe qui a écrit le code est celle qui reçoit l’alerte, ces défaillances cessent d’être le problème de quelqu’un d’autre à documenter et deviennent votre propre week-end. C’est une contrainte de conception remarquablement efficace.

Ce que ça change avant le lancement

Savoir que nous exploiterons quelque chose nous pousse à le construire autrement, et presque toujours plus simplement. L’astuce coûte cher quand c’est vous qui en payez la maintenance.

• Chaque choix de stack est un choix que nous avons nous-mêmes exploité en production. Nous ne tenons pas à découvrir ce qu’une base de données fait sous charge pour la première fois sur le trafic d’un client.
• La supervision et les alertes arrivent avant le premier vrai utilisateur, pas après la première panne. Si nous ne pouvons pas voir un système, nous ne le considérons pas comme lancé.
• Moins de pièces mobiles vaut mieux qu’une architecture plus élégante. Chaque service ajouté est une chose de plus qui peut tomber à trois heures du matin.
• Si une fonctionnalité ne peut être expliquée que par la personne qui l’a écrite, elle n’est pas terminée. Du code qu’on ne peut pas confier à la personne d’astreinte est un passif avec une belle interface.

La production est la revue de design. Tout ce qui précède est une répétition.

Le compromis

Ce modèle ne passe pas à l’échelle comme une agence est censée le faire. Nous prenons peu de projets à la fois, nous restons des années, et nous disons non bien plus souvent que oui, généralement parce que nous ne pouvons pas ajouter de façon responsable un produit de plus à ceux que nous maintenons déjà en vie.

Ce que vous obtenez en retour, c’est un studio sans aucune incitation à laisser quelque chose à moitié fini. Il n’y a aucun point où nos intérêts et les vôtres divergent, parce que ce que nous avons construit est ce avec quoi nous devons vivre.

Vous travaillez sur quelque chose qui correspond ? Parlez-nous-en.