BlackMesa Labs

Notre couche Domaine ne contient que des exceptions. C'est délibéré.

2026-10-04T00:00:00+00:00

Les articles sur l’architecture hexagonale montrent presque toujours le même schéma : un cercle au milieu, des ports tout autour, des adaptateurs à l’extérieur, et une flèche qui rentre. Aucun ne montre ce que contient le dossier Domain/ six mois après.

Voici le nôtre. Neuf contextes, et au total douze fichiers de domaine : neuf exceptions, deux énumérations, un rôle. Zéro interface. Zéro agrégat. Zéro objet-valeur. Appeler ça une couche métier serait un mensonge, et c’est précisément le sujet de cet article.

Ce qu’on a gardé : le C de CQRS, pas le Q

La configuration du bus déclare trois canaux, avec une sémantique explicite :

default_bus: command.bus
buses:
    command.bus:            # une commande mute l'état, exactement un gestionnaire
        default_middleware: { enabled: true, allow_no_handlers: false }
    query.bus:              # une requête renvoie une valeur, un seul gestionnaire
        default_middleware: { enabled: true, allow_no_handlers: false }
    event.bus:              # un événement de domaine : 0..n abonnés
        default_middleware: { enabled: true, allow_no_handlers: true }

Le décompte réel, aujourd’hui : vingt-neuf gestionnaires de commande, un seul gestionnaire de requête. Le bus de requêtes existe, il est configuré, il est presque vide.

Ce n’est pas un retard de migration, c’est une conclusion. Une commande vaut sa cérémonie parce qu’elle apporte trois choses qu’on n’avait pas : un nom d’intention (ChangeCompanySubscriptionPlan n’est pas setSubscriptionPlan), la garantie qu’il existe exactement un endroit qui l’exécute — allow_no_handlers: false échoue au démarrage, pas en production — et une frontière de transaction évidente, celle du gestionnaire.

Une lecture n’apporte rien de tout ça. Sa forme est dictée par l’écran qui l’affiche : cette page a besoin de ces sept colonnes, jointes de cette façon, triées comme ça. Faire passer ça par un bus n’ajoute aucune règle, ajoute une couche, et déplace le SQL d’un fichier à un autre. On lit donc par les dépôts Doctrine, directement, sans s’en excuser.

Détail qui compte plus qu’il n’en a l’air : default_bus: command.bus. Un dispatch() nu est une commande. La valeur par défaut est celle qui mute l’état, donc la seule qu’on ne veut jamais voir partir par accident sur le mauvais canal.

Ce qu’on a refusé : l’inversion de dépendance

C’est le cœur de l’hexagone dans la littérature : le domaine définit des interfaces, l’infrastructure les implémente, la flèche de dépendance pointe vers l’intérieur. On ne l’a pas fait. Voici un gestionnaire entier, sans coupe :

#[AsMessageHandler(bus: 'command.bus')]
final readonly class ChangeCompanySubscriptionPlanHandler
{
    public function __construct(
        private EntityManagerInterface $entityManager,
        private LoggerInterface $logger,
    ) {}

    public function __invoke(ChangeCompanySubscriptionPlanCommand $command): void
    {
        $company = $this->entityManager->find(Company::class, Ulid::fromString($command->companyId));
        if (!$company instanceof Company) {
            throw CompanyNotFoundException::withId($command->companyId);
        }
        // …
    }
}

EntityManagerInterface en dépendance directe. Sur trente-huit gestionnaires, vingt-quatre en dépendent. L’entité Company vient de App\Entity, partagée par tous les contextes. Il n’y a pas de dépôt abstrait, pas de port, pas de modèle de domaine distinct de la table.

Deux remarques sur cet exemple, parce qu’elles disent plus que le schéma.

D’abord, la commande transporte string $companyId, pas un objet-valeur CompanyId. Ce n’est pas de la paresse : le message doit pouvoir être sérialisé pour le transport asynchrone. La frontière du bus impose la forme du message — de l’infrastructure qui dicte la signature de ce qu’on appelle le domaine, dès la première ligne.

Ensuite, Ulid::fromString(...). L’identifiant du domaine existe en deux formes selon qu’on le transporte ou qu’on l’interroge, et la conversion est une contrainte du stockage, pas du métier.

Ce que la frontière achète quand même

Une chose, une seule, et elle vaut son prix : le couplage entre contextes est devenu visible dans la liste des imports.

Le gestionnaire ci-dessus vit dans App\Billing. Il importe App\Company\Domain\Exception\CompanyNotFoundException. Ce seul import dit que la facturation dépend du contexte Entreprise, et il le dit en haut du fichier, en une ligne, sans diagramme à tenir à jour. Le graphe de dépendances entre contextes s’obtient avec un grep sur les use.

C’est modeste. Comparé à une base où tout vit dans App\Service, c’est la différence entre « on suppose que c’est couplé » et « voilà exactement où ». C’est ce bénéfice-là qu’on a acheté, et rien d’autre.

Les cinq endroits où l’infrastructure traverse

Voilà ce qu’aucun schéma ne montre : les endroits où Doctrine décide de la forme d’une opération métier. Ce sont des fuites réelles, toutes présentes dans le code aujourd’hui.

1. La règle métier écrite en deux dialectes. Notre politique d’exclusion des entreprises internes des chiffres commerciaux tient en un prédicat. Elle existe en deux versions, parce que certains chemins de lecture sont en SQL natif pour la performance et d’autres en DQL :

public static function sql(string $alias = 'c'): string  // requêtes natives
{ return ($alias !== '' ? $alias.'.' : '').'excluded_from_stats = false'; }

public static function dql(string $alias = 'c'): string  // requêtes de l'ORM
{ return $alias.'.excludedFromStats = false'; }

Une règle, deux écritures, à cause du langage de requête. La divergence est d’un caractère — excluded_from_stats contre excludedFromStats — donc invisible à la relecture rapide, et il n’existe aucun test qui échouerait si l’une des deux partait à la dérive.

2. Le filtre ambiant. Le filtre de suppression logique de Doctrine est un état global mutable. Une requête qui cherche un identifiant unique ne trouve rien alors que l’index unique, lui, le retient toujours. On s’en sort en désactivant le filtre, puis en le remettant :

$filters = $this->em->getFilters();
$wasEnabled = $filters->isEnabled('softdeleteable');
if ($wasEnabled) { $filters->disable('softdeleteable'); }
$existing = $repo->findOneBy(['slug' => $slug]);
if ($wasEnabled) { $filters->enable('softdeleteable'); }

Une « requête métier » dont le résultat dépend d’un état ambiant n’est pas une fonction. Ce n’est pas un défaut de Doctrine — le filtre est exactement ce qu’on lui demande — mais ça interdit de raisonner sur le code applicatif sans savoir dans quel mode il s’exécute.

3. L’ordre des écritures dans l’unité de travail. Remplacer les traductions d’un contenu semble être une opération : on retire les anciennes, on ajoute les nouvelles, on enregistre. Dans un seul flush(), Doctrine exécute les INSERT avant les DELETE d’orphelins, et la contrainte d’unicité sur (feedback_id, locale) casse. L’opération doit être coupée en deux enregistrements successifs.

Autrement dit : la découpe de l’opération applicative n’est pas dictée par le métier mais par l’ordonnancement interne de l’ORM. Aucun port n’aurait protégé de ça, parce que la contrainte ne vit ni dans le domaine ni dans l’adaptateur — elle vit dans le calendrier d’exécution qui les relie.

4. L’alias de jointure qui tronque en silence. Filtrer sur une association déjà jointe en fetch restreint aussi la collection hydratée : on croit filtrer les lignes, on ampute l’objet retourné. Il faut une seconde jointure dédiée au filtrage :

$qb->innerJoin('f.industries', 'i_filter')      // alias distinct de celui du fetch
   ->andWhere('i_filter.id IN (:industries)');

Le bug ne se voit pas : la requête renvoie les bonnes entités, avec des collections incomplètes. C’est de la sémantique d’infrastructure, au beau milieu de ce qui ressemble à une règle de recherche.

5. Le type de l’identifiant. Les identifiants circulent en ULID, se comparent en RFC 4122 dans les requêtes, et l’oubli de la conversion produit un résultat vide plutôt qu’une erreur. Un port aurait déplacé la conversion ; il ne l’aurait pas supprimée.

La règle de migration

Reste la question qui tue les refontes : que fait-on du code existant, écrit en services Symfony classiques ?

Rien, tant que personne ne le touche. La politique est écrite : CQRS pour les nouvelles écritures et les nouvelles lectures ; migration de l’existant à la demande uniquement. Jamais de réécriture en masse au nom de l’homogénéité.

Parce que l’homogénéité n’est pas un résultat métier. Réécrire un service qui fonctionne pour qu’il ressemble à ses voisins, c’est produire du risque sans produire de valeur — et c’est exactement le genre de travail qui se justifie tout seul, indéfiniment, parce que son critère d’arrêt est esthétique.

Ce n’est pas du DDD puriste, c’est du time to market

Il faut nommer la vraie raison, parce que tout ce qui précède se lit autrement une fois qu’elle est posée.

On a déjà écrit ici que la fonctionnalité la moins chère est celle qu’on ne construit pas. Un port est une fonctionnalité. Un agrégat aussi, un objet-valeur aussi, une couche anticorruption aussi. Chacun a un coût d’écriture, un coût de lecture pour celui qui arrivera après, et un coût d’entretien qui court aussi longtemps que le code vit. Une abstraction n’est pas gratuite parce qu’elle est immatérielle.

La question utile n’est donc pas « est-ce du DDD correct ». C’est : qu’est-ce que cette abstraction achète aujourd’hui, et qu’est-ce qu’elle se contente de repousser ? Un dépôt derrière une interface achète la possibilité de changer de stockage — nous ne quitterons pas PostgreSQL. Il achète aussi des tests sans base de données, et ça, c’est un vrai bénéfice : c’est le seul argument qui nous fera peut-être payer la facture un jour.

Ce qu’on a fait à la place tient en une phrase : livrer, et ne garder que les frontières qui se paient toutes seules. Le bus de commandes coûte trois fichiers et rend service le jour même. Les ports coûtent une couche entière et rendront peut-être service, plus tard, à une équipe qui n’existe pas encore.

Le risque de cette position est connu, et l’écrire fait partie du prix : elle ressemble à s’y méprendre à de la paresse. La différence tient à un seul détail — on sait nommer ce qu’on n’a pas construit, et pourquoi.

Et on assume. Ces choix sont les nôtres, pas des accidents qu’on découvrirait en relisant. On les corrige quand on peut et quand on a le temps : le jour où une gêne devient réelle et mesurable, pas le jour où un article d’architecture nous explique qu’ils sont incorrects. Une dette écrite, datée et argumentée n’est pas une dette niée — c’est la seule qu’on soit capable de rembourser au bon moment.

Ce que ça a donné

Neuf contextes nommés, dont le couplage mutuel se lit dans les imports plutôt que dans un diagramme périmé.
Vingt-neuf commandes, chacune avec un nom d’intention, un gestionnaire unique garanti au démarrage et une frontière de transaction évidente.
Un seul gestionnaire de requête, assumé : les lectures passent par les dépôts.
Douze fichiers de domaine — neuf exceptions, deux énumérations, un rôle — c’est-à-dire aucune règle métier réellement isolée de Doctrine.
Zéro réécriture du code classique existant, qui continue de fonctionner à côté.

Bonnes pratiques

Traiter chaque abstraction comme une fonctionnalité : elle doit dire ce qu’elle achète aujourd’hui, pas ce qu’elle permettrait un jour.
Adopter les morceaux séparément. Le bus de commandes apporte quelque chose sans le reste ; les ports, les agrégats et les objets-valeurs sont des achats distincts, avec chacun leur facture.
Choisir la valeur par défaut la plus contraignante : le bus par défaut est celui qui mute l’état, et l’absence de gestionnaire fait échouer le démarrage plutôt que la production.
Se servir des espaces de noms comme d’un révélateur de couplage plutôt que comme d’une barrière : ils ne protègent de rien, ils rendent visible.
Écrire la règle de migration, avec son critère d’arrêt. Sans critère d’arrêt, « harmoniser l’architecture » est un travail infini.
Regarder ce que contient réellement Domain/ avant de dire qu’on fait du DDD. Le décompte est instructif.

Points de vigilance

Le dossier n’est pas la frontière. Créer Domain/, Application/, Infrastructure/ donne une impression d’avancement mesurable — et mesurer une architecture au nombre de dossiers est la meilleure façon de n’obtenir aucune des garanties qu’ils suggèrent.
Vingt-quatre gestionnaires sur trente-huit dépendent de l’EntityManager : aucun ne peut être testé avec un dépôt en mémoire. La suite de tests a besoin d’une vraie base. C’est un coût, il est assumé, il n’est pas gratuit.
Les entités Doctrine partagées sont le vrai couplage, et il est invisible dans l’arborescence. Le jour où deux contextes voudront faire diverger la même table, c’est ce mur-là qu’on rencontrera, pas l’absence de ports.
Une règle métier dupliquée dans deux dialectes de requête finira par diverger, et aujourd’hui rien ne le détecterait. C’est la dette la plus concrète de tout ce qui précède.

Nous étions notre propre meilleur client. C'était un bug.

2026-09-30T00:00:00+00:00

On recommande à tout le monde d’utiliser son propre produit. Personne ne prévient de l’effet secondaire : à partir du moment où votre entreprise a un compte, elle entre dans vos chiffres. Pas dans une note de bas de page — dans le chiffre d’affaires, dans le taux de conversion, dans les listes de clients à relancer.

Notre cas : BlackMesa publie de vrais retours d’expérience sur Show me the REX. Le compte est réel, le plan est réel, les articles sont lus. Ce qui n’est pas réel, c’est le revenu : on ne se facture pas. Résultat, un client à zéro euro figurait dans le MRR, gonflait la répartition par plan, et remplissait une case du funnel de conversion sans avoir jamais rien converti.

La correction évidente — « on exclut notre entreprise » — est fausse. Elle suppose que le problème est l’entreprise. Le problème est ailleurs.

Ce n’est pas « qui exclure », c’est « qu’est-ce que ce chiffre répond »

Le réflexe est de chercher une liste d’entités à écarter. La bonne question se pose métrique par métrique : à quelle question ce chiffre sert-il de réponse ?

Un compteur de vues répond à « combien de personnes ont lu ce texte ». La réponse est la même que le lecteur vienne de chez nous ou d’ailleurs : la page a été servie, elle a été lue, le contenu existe. Exclure nos vues rendrait ce chiffre faux.

Un chiffre d’affaires mensuel répond à « combien nous paient nos clients ». Notre propre entreprise n’est pas un client. Sa présence rend ce chiffre faux.

Les deux métriques regardent la même base de données, parfois la même ligne, et ont besoin de règles opposées. Ce n’est pas une exception à gérer, c’est la règle : l’unité d’exclusion n’est pas la donnée, c’est la question posée.

Le cas qui tranche : une vue qui compte et ne compte pas

Le meilleur exemple est aussi le plus inconfortable, parce qu’il interdit tout raccourci d’implémentation.

Sur la plateforme, une vue de REX alimente deux choses distinctes. D’un côté l’audience : le compteur affiché sur l’article, le cumul du tableau de bord, la courbe de fréquentation. De l’autre un signal commercial : « quelles entreprises ont consulté vos REX », qui sert à identifier des contacts à relancer.

Même événement, même enregistrement. Dans le premier groupe, une lecture faite depuis chez nous compte — quelqu’un a vraiment lu. Dans le second, elle ne doit surtout pas compter : nous ne sommes pas un prospect à rappeler, et un lecteur interne dans une liste de leads, c’est une action commerciale déclenchée pour rien.

Il n’existe donc pas de filtre global qu’on poserait une fois à l’entrée. Chaque requête doit savoir à quelle famille elle appartient.

Un drapeau en base, pas une constante dans le code

Première version, la plus rapide : une liste de noms d’entreprises en dur. Elle a tenu une heure. Une constante oblige à un déploiement pour reclasser une entreprise, et surtout elle ment sur la nature de l’information : « cette entreprise n’est pas un client » est une donnée métier, qui change, qui se décide, et qui doit être visible par la personne qui administre les comptes.

C’est donc devenu une case à cocher sur la fiche entreprise — avec son texte d’aide écrit noir sur blanc, parce qu’une option dont personne ne comprend la portée finit cochée au hasard :

Nos propres entreprises publient et restent visibles en front, mais ne comptent dans aucune donnée commerciale ou marketing : MRR, plans, funnel, upsell/churn, leads, récaps. Les vues et visites, elles, restent comptées.

La liste de noms n’a pas disparu pour autant : elle sert d’amorçage, pour qu’un environnement fraîchement installé ne démarre jamais avec des chiffres pollués. Mais elle ne décide plus rien.

Le prédicat lui-même vit dans une seule petite classe, en deux versions — une pour les requêtes de l’ORM, une pour le SQL brut. Ça paraît anecdotique ; c’est ce qui rend la règle auditable. Chercher les endroits qui l’appliquent est devenu une recherche de texte, et la comparaison avec la liste des chiffres commerciaux se fait à l’œil en une minute.

Vérifier plutôt que relire

Relire son propre code d’exclusion ne prouve rien : on relit ce qu’on croit avoir écrit. La seule vérification qui vaille consiste à basculer la case et à comparer les tableaux de bord avant et après, chiffre par chiffre.

Une trentaine de valeurs se sont déplacées. Sept sont restées rigoureusement identiques — et c’était le résultat attendu : ce sont les compteurs d’audience et les volumes de contenu publié. Un chiffre qui bouge alors qu’il ne devait pas est un bug ; un chiffre qui ne bouge pas alors qu’il aurait dû est un oubli. Sans ce passage, on n’aurait distingué ni l’un ni l’autre.

Au final : un drapeau, une classe de politique, trente-quatre prédicats répartis sur huit fichiers — MRR, plans, funnel, upsell, risque de départ, relances, intelligence commerciale, récapitulatifs mensuels, expiration des codes promo, nurturing.

Ce dernier mérite une mention. Sans l’exclusion, notre propre entreprise entrait dans la séquence de relance automatique. On se serait envoyé nos propres e-mails de réengagement.

Ce que ça a donné

Un MRR qui ne contient plus de client à zéro euro, et un taux de conversion qui ne compte plus notre propre inscription dans son dénominateur.
Une trentaine de valeurs corrigées sur les tableaux de bord commerciaux, sept volontairement inchangées.
Zéro changement en front : les REX restent publiés, visibles, filtrables, et leurs vues comptent toujours.
Une règle écrite à un seul endroit, avec la raison, plutôt qu’un AND recopié de requête en requête.
Une case à cocher qui permet de reclasser une entreprise sans déployer.

Bonnes pratiques

Classer chaque métrique avant de coder le filtre : mesure d’audience, ou signal commercial. La réponse détermine la règle, et elle n’est pas la même pour deux chiffres issus de la même table.
Mettre l’appartenance en base, pas dans une constante : c’est une donnée métier, elle change et elle se décide.
Concentrer le prédicat dans une classe unique, même s’il tient en une ligne : ce qui compte n’est pas la réutilisation, c’est de pouvoir retrouver tous les appels.
Vérifier en basculant : comparer les chiffres avant et après est le seul moyen de distinguer un oubli d’une décision.
Écrire le périmètre dans l’interface d’administration, à l’endroit où la case se coche.

Points de vigilance

Rien n’empêche la prochaine requête d’oublier le prédicat. La règle est tenue par la relecture, pas par un test, et c’est aujourd’hui la faiblesse principale du dispositif.
Une exclusion trop large est aussi fausse qu’une exclusion absente : retirer nos vues du compteur d’audience aurait produit un chiffre mensonger dans l’autre sens.
Le jour où une entreprise interne devient un vrai client payant, la case doit se décocher — et personne ne le rappellera. La décision est humaine, elle a besoin d’un moment où on la reprend.
Dire publiquement que vos statistiques excluent vos propres données ne coûte rien, et vaut mieux que de le découvrir à la place de quelqu’un d’autre.

La fonctionnalité la moins chère est celle qu'on ne construit pas

2026-09-27T00:00:00+00:00

La sobriété numérique se pose presque toujours comme un problème d’optimisation : des images plus légères, un meilleur cache, une région plus propre. Tout est vrai, et tout est marginal. Le vrai gaspillage est ailleurs, et personne ne le mesure : le code écrit pour rien. Une migration à refaire, un outil acheté puis abandonné, une fonctionnalité livrée que personne n’ouvre. Reste la question qu’on n’avait jamais formulée : comment décide-t-on de ne pas construire quelque chose ?

Le REX donne les trois signaux qu’on s’est donnés, et ce que chacun a économisé sur une journée de travail ordinaire : une fonctionnalité cassée dont personne ne s’est plaint — information sur la fonctionnalité, pas sur le bug ; 1 400 traductions qu’on n’a pas écrites parce qu’aucun lecteur ne pouvait les atteindre ; et un manque de supervision qui s’est révélé être un manque de répétition, pas un manque d’outil.

Il dit aussi ce que ces signaux ne disent pas. « Personne n’en a besoin » est l’excuse parfaite pour ne rien faire, et une règle qui ne sait dire que non a cessé d’être une règle. Deux garde-fous la gardent honnête — dont celui-ci : une fonctionnalité inutilisée est parfois mal exposée plutôt qu’inutile.

Monter l'OS sous Docker : ce qui reste couplé, et ce que rien ne valide

2026-09-27T00:00:00+00:00

Show me the REX tourne sur un hôte unique : un Postgres, un Redis, un proxy frontal, et l’application déployée en blue-green — deux instances identiques, « bleue » et « verte », dont une seule sert le trafic à la fois. La nouvelle version est démarrée sur celle qui dort, et quand elle répond correctement, on bascule le proxy dessus. Au moment où nous écrivons, cet hôte sert 52 REX publiés et un peu plus de 16 000 vues cumulées.

Ce dispositif protège une livraison : si la nouvelle version se comporte mal, rebasculer prend une seconde et personne ne s’en aperçoit. Il ne protège rien du tout contre la machine elle-même, puisque les deux instances vivent sur ce même hôte — arrêtez-le, vous les arrêtez toutes les deux.

L’hôte unique est un choix assumé, pas une négligence : pas de redondance tant que le trafic ne la justifie pas, et le seuil de révision est écrit — mille visites par jour. En dessous, une seconde machine coûte bien plus en complexité (réplication, bascule, cohérence) qu’elle ne rapporte en disponibilité, et la complexité dont personne n’a encore besoin est la chose la plus chère qu’on puisse construire.

Assumer ce choix crée une obligation, en revanche. Si on accepte qu’un redémarrage coupe le service, on se doit d’avoir le chiffre exact de ce que ça coûte. C’est précisément là qu’on s’est plantés cette nuit-là, et on y revient à la fin.

Nous avons fait passer cet hôte d’une version d’Ubuntu à la suivante. L’opération est passée, et ce n’est pas l’intéressant. L’intéressant, c’est que la conteneurisation a réduit ce qu’une telle montée peut encore casser à une liste très courte — et que nous y avons trouvé précisément l’élément que rien, dans notre chaîne, ne surveillait.

Ce que la conteneurisation a réellement découplé

L’application est immunisée contre une montée de version, et il vaut la peine d’être précis sur le pourquoi : elle n’utilise rien de l’hôte. Son PHP, ses extensions, ses bibliothèques système, son magasin de certificats voyagent dans l’image. On peut remplacer intégralement le ca-certificates de la machine : nos appels sortants vers VIES, le prestataire de paiement et le stockage objet n’en savent rien, parce qu’ils ne lisent jamais ce magasin.

C’est pour ça que les équipes en sont venues à traiter une montée d’OS sur un hôte de conteneurs comme une routine. C’est presque vrai, et c’est ce « presque » qui coûte.

Les quatre points de couplage qui restent

Une fois qu’on a mis en image tout ce qui pouvait l’être, ce qui appartient encore à l’hôte tient en une liste courte — et c’est la même sur n’importe quel serveur conteneurisé :

Le noyau. Les conteneurs le partagent. Un saut majeur change le sol sous une base de données bien davantage que sous un processus web.
Le démon Docker. Il n’est pas dans votre image : c’est un paquet de l’hôte, installé depuis un dépôt tiers.
Les sources apt de ce démon. Ce qui décide si le point précédent recevra encore un correctif de sécurité un jour.
Le contrat de redémarrage. Quels conteneurs reviennent seuls après un boot, et lesquels, délibérément, non — l’instance en sommeil, par exemple, doit rester à terre, sinon deux versions de l’application se disputeraient la même base.

Rien d’autre ne compte vraiment. Cette liste est assez courte pour être vérifiée à la main, avant et après — ce qui rend impardonnable de ne pas la vérifier.

Le seul dégât durable est tombé sur le point trois

Une montée de version désactive ou supprime les sources apt tierces. Ce n’est pas un défaut : ces sources sont compilées pour la version qu’on quitte, et les garder actives pendant le saut est la meilleure façon de casser le système. L’outil a raison de le faire, et il le dit.

Ce qu’il ne fait pas, c’est vous le rappeler ensuite. Notre source Docker avait disparu. Rien n’était cassé : le démon tournait, les conteneurs avec, le site servait. Mais le paquet installé était compilé pour la distribution précédente, et plus aucun dépôt n’était en mesure de le remplacer. Le mode de défaillance n’est pas un service qui s’arrête ; c’est un gestionnaire de paquets qui devient à la fois autoritaire et vide. Il annonce que tout est à jour, et il dit vrai à propos d’un univers qu’il ne voit plus.

Rétablir la source tient en quatre lignes, sans redémarrage. Ça a révélé sur-le-champ sept versions mineures de dérive accumulées en silence. Rien n’aurait jamais levé la main : ni le démon, qui fonctionne ; ni la supervision que nous n’avons pas ; ni apt, qui n’avait plus rien à quoi se comparer.

L’angle mort : les fichiers compose

Vient ensuite le constat structurel, celui qui mérite d’être emporté.

Notre service de base de données n’avait pas de politique de redémarrage. Après un boot, tous les autres conteneurs seraient revenus, et pas Postgres. Le défaut est trivial : une ligne manquante. Sa durée de vie ne l’est pas : il était là depuis des mois, et il ne pouvait se manifester qu’au redémarrage de l’hôte — lequel n’était pas survenu de tout ce temps.

La bonne question n’est pas comment il a été écrit. C’est pourquoi rien ne l’a attrapé. Et la réponse se généralise bien au-delà de notre installation : les fichiers compose sont la seule configuration de production que personne ne possède. Ils ne sont pas cuits dans l’image, donc la construction ne les voit jamais. Aucun test ne les exerce, parce que les tests tournent contre l’application, pas contre la topologie de l’hôte. Et notre job de déploiement ne les copie même pas : il ouvre une session SSH et lance un script. Ils sont édités dans le dépôt, appliqués à la main, et validés par rien.

Dans une chaîne par ailleurs entièrement automatisée — tests, analyse statique, construction d’image, déploiement sans coupure — c’est là qu’un défaut peut dormir indéfiniment. Pas dans le code que la chaîne relit vingt fois par jour, mais dans la poignée de lignes de YAML qu’elle n’ouvre jamais.

Ce que le noyau aurait pu casser, et ce que nous n’avons pas vérifié

Un saut majeur de noyau sous un Postgres conteneurisé mérite mieux que « ça a redémarré ». Trois questions valent d’être posées, et nous ne pouvons en trancher que deux :

Le répertoire de données. Il vit dans un volume nommé, sur le même système de fichiers, avec le même pilote de stockage. Rien n’a bougé — et c’est la raison pour laquelle la montée était survivable, pas la chance.
Les profils de confinement du démon. Les valeurs par défaut seccomp et AppArmor arrivent avec le paquet Docker, pas avec la distribution : c’est pourquoi les conteneurs ont retrouvé le même environnement de l’autre côté.
La sémantique de durabilité. Savoir si un nouveau noyau change quoi que ce soit pour Postgres avec nos options de montage est une question à laquelle nous n’avons pas répondu. Ça a tenu, ce qui ne prouve rien. Nous l’écrivons plutôt que de revendiquer une vérification que nous n’avons pas faite.

La mesure existait déjà

Reste l’obligation posée en introduction : connaître le coût réel de la coupure qu’on a choisi d’accepter. Nous avons annoncé une durée en lisant les journaux des conteneurs : l’écart entre la dernière erreur d’un processus et le démarrage du suivant. Ce nombre décrit l’hôte, pas les visiteurs. Il exclut l’arrêt qui précède et la montée en charge qui suit, et il peut se tromper d’un facteur trois.

Pendant ce temps, tout notre trafic passe par un CDN qui avait déjà enregistré, requête par requête, exactement ce que les gens ont reçu sur cette fenêtre. La mesure qu’on croyait ne pas avoir avait été prise pour nous, par un équipement qu’on payait et qu’on n’avait jamais interrogé.

Le réflexe à corriger n’est pas « ajouter de l’instrumentation ». C’est inventorier ce qui mesure déjà avant d’ajouter quoi que ce soit : le CDN, les journaux du proxy lui-même, la console du fournisseur. Nos maladresses de procédure cette nuit-là — un nom de conteneur deviné, des variables de shell qui ne survivent pas à une reconnexion SSH, un grep assez large pour remonter 41 lignes pour 2 erreurs — appartiennent toutes à la même famille et valent exactement une phrase : un runbook résout ce dont il a besoin, il ne le fige jamais. Savoir quelle instance sert le trafic en est le cas d’école : ça change à chaque déploiement.

Pourquoi on publie tout ça — et la seule chose qu’on garde

Un REX n’a de valeur que s’il est précis, celui-ci porte donc les commandes, les modes de défaillance et les trous. Ce qui soulève une question légitime : publier tout ça, n’est-ce pas offrir une carte à un attaquant ?

Notre règle tient en une phrase. Le problème n’est jamais de nommer une version. C’est de nommer une version sur laquelle on est encore vulnérable.

« On était en version X, ça nous a coûté ça, c’est corrigé » est une pratique de post-mortem ordinaire. Le même texte publié avant le correctif est une faiblesse encore vraie avec la cible attachée — un REX est signé, il nomme une entreprise et un domaine. Donc : corriger d’abord, raconter ensuite, et généraliser ce qui n’apprend rien. L’écart — sept versions de dérive silencieuse — c’est la leçon ; la chaîne de version exacte de notre serveur, non. Ce qu’on ne publie jamais, c’est l’autre catégorie, celle qui ne s’apprend pas mais se recopie : noms de machines, chemins, la chaîne de clés qui déchiffre une sauvegarde. La frontière n’est pas « sensible ou anodin », elle est : est-ce que ça enseigne, ou est-ce que ça ouvre ?

Ce que ça a donné

Quatre points de couplage isolés entre une application conteneurisée et son hôte : noyau, démon, sources apt du démon, contrat de redémarrage. Assez peu nombreux pour être vérifiés à la main, avant et après.
Une voie de mise à jour gelée, rétablie : le démon avait dérivé de sept versions mineures sans que rien puisse le signaler.
Un angle mort structurel, nommé : les fichiers compose, seule configuration de production qu’aucune construction, aucun test et aucun déploiement ne lisent jamais.
Une mesure récupérée plutôt que construite : le CDN avait déjà enregistré ce que les visiteurs ont vu, gratuitement.

Bonnes pratiques

Écrire ses points de couplage une fois pour toutes. Sur un hôte de conteneurs il y en a quatre, ce sont toujours les mêmes, et les vérifier prend dix minutes.
Après une montée de version, re-vérifier d’abord les sources tierces : un gestionnaire de paquets qui n’a plus rien à quoi se comparer annonce que tout est à jour, et il ne ment pas.
Chercher ce que l’automatisation ne possède pas. Dans une chaîne entièrement automatisée, le défaut qui survit est dans le fichier que la chaîne n’ouvre jamais.
Inventorier ce qui mesure déjà — CDN, proxy, console du fournisseur — avant d’ajouter de l’instrumentation. Le chiffre qui vous manque a souvent déjà été enregistré.
Un runbook résout, il ne fige pas : quelle instance sert le trafic, son nom de conteneur, l’identifiant du service — tout ça se demande au moment de l’appel.

Points de vigilance

La panne dangereuse n’est pas le service qui s’arrête, c’est celui qui continue de fonctionner en perdant sa capacité à être mis à jour. Il n’émet rien.
« Ça a redémarré » ne prouve rien sur la durabilité. Écrire les questions auxquelles on n’a pas répondu plutôt que revendiquer une vérification qu’on n’a pas faite.
Un défaut qui ne peut se manifester qu’au redémarrage de l’hôte a la durée de vie de l’intervalle entre deux redémarrages. Sur un serveur qui se tient bien, c’est des mois.
Un journal interne dit quand un processus est mort, jamais quand les visiteurs ont cessé d’être servis. Seule une mesure prise devant la pile le dit.
Corriger avant de raconter : un REX qui décrit une faiblesse encore ouverte, signé de son nom, n’est pas de la transparence — c’est une notice d’utilisation.

Construire un SaaS complet, prêt pour la production, avec un agent de code

2026-09-26T00:00:00+00:00

Comment on a conçu, sécurisé et déployé une plateforme entière — bascule blue-green sans coupure, prélèvements bancaires réels, connexion par passkey, site trilingue, sauvegardes chiffrées — en travaillant en binôme avec un agent de code.

Le REX détaille l’architecture retenue, ce que l’agent a réellement accéléré, et surtout les endroits où il a fallu reprendre la main.

Garantir des retours d'expérience légitimes sans équipe de modération

2026-09-25T00:00:00+00:00

Une plateforme de retours d’expérience ne vaut que par la confiance qu’on accorde à ce qui y est publié. Un seul faux témoignage, et c’est la crédibilité de tout le corpus qui vacille. La question qu’on s’est posée : comment garantir la légitimité de chaque publication, à l’échelle, sans monter une équipe de modération — ni confier le tri à une IA, qui juge la forme d’un texte et non la légitimité de celui qui le publie ?

Notre réponse remplace la modération du contenu par la vérification de l’émetteur : pas d’entreprise, pas de publication ; une substance minimale exigée ; un numéro de TVA intracommunautaire validé auprès du registre européen ; une traçabilité complète.

Le REX raconte aussi les deux pièges rencontrés en chemin, tous deux dans la même famille : un service tiers qui répond 200 OK sans avoir pu vérifier quoi que ce soit, puis un état « inconnu » qui recouvrait en réalité deux situations opposées — « je n’ai pas pu vérifier maintenant » et « je ne pourrai jamais vérifier cette valeur ». Le second a laissé passer n’importe quelle chaîne de caractères pendant des mois.