93 % du code n'était jamais relu. On a fermé la porte.

Avant de décider quoi que ce soit, nous avons compté. C'est une habitude qui évite beaucoup de débats : les intuitions sur « comment on travaille » sont rarement justes, et elles sont vérifiables en une requête.

Sur quatre-vingt-dix jours, à travers l'ensemble de nos dépôts actifs :

• 63 commits sont arrivés sur la branche principale par une demande de fusion,
• 855 commits y sont arrivés par un envoi direct,
• soit 721 envois directs, dont 41 ont cassé la chaîne d'intégration.

93 % de ce qui atteignait la branche principale n'était jamais passé par une relecture. Et cette branche est le déclencheur de mise en production : ce qui y arrive part en ligne.

Ce qui protégeait déjà, et ce que ça ne couvrait pas #

Le garde-fou existant n'était pas rien. L'étape de déploiement dépend des étapes de compilation et de tests : un commit cassé ne se déploie pas. Sur les 41 envois qui ont fait rougir la chaîne, aucun n'est parti en production.

Mais la branche principale restait rouge — c'est-à-dire que la référence commune de l'équipe était cassée, parfois plusieurs heures, jusqu'à ce que quelqu'un s'en aperçoive. Et surtout, ce dispositif ne protège que du code qui échoue. Il ne protège pas du code qui passe et qu'on n'avait pas l'intention d'envoyer.

La décision : fermer, sans ajouter de cérémonie #

Nous avons interdit l'envoi direct sur la branche principale de tous les dépôts actifs, avec exigence que les tests soient verts avant fusion, et application de la règle y compris aux administrateurs.

En revanche, aucune approbation n'est requise. Ce point mérite d'être expliqué, parce que c'est le réflexe que tout le monde a et c'est presque toujours une erreur en petite équipe.

La plupart des forges interdisent d'approuver sa propre demande de fusion. Exiger une approbation dans une équipe où une personne travaille seule sur un projet, c'est créer une impasse : plus rien n'est jamais fusionnable. La protection sert ici à garantir que les tests sont passés, pas à simuler une revue par les pairs qui n'existe pas.

Le résultat, côté quotidien : on travaille sur une branche, on ouvre une demande de fusion, les tests tournent, on clique. Pas d'attente, pas de dépendance à un tiers. La seule chose qui devient impossible, c'est d'écrire directement dans ce qui part en production.

Quatre pièges, tous rencontrés #

Cette mise en place est réputée triviale. Elle ne l'est pas, et les quatre pièges suivants se ressemblent tous : ils produisent une configuration qui a l'air bonne et qui ne fait pas ce qu'on croit.

1. Le nom du contrôle contient l'événement #

Le contrôle ne s'appelle pas « tests » mais « tests (pull_request) ». Exiger le nom sans son suffixe ne correspond à rien : la demande de fusion reste bloquée pour toujours, sans message utile. Nous avons relevé les noms exacts dans la base de la forge plutôt que de les deviner.

2. Une étape sautée n'est pas une étape réussie #

L'étape de déploiement est volontairement sautée sur une demande de fusion. Elle remonte donc l'état « sauté », qui n'est pas « réussi ». L'exiger dans la liste des contrôles bloque toutes les fusions, définitivement.

3. Les dépôts sans chaîne d'intégration #

Tout dépôt n'a pas de chaîne d'intégration — outillage interne, bibliothèque partagée, dépôt de documentation. Y exiger un contrôle vert reviendrait à le geler. Ces dépôts-là se protègent sans exigence de test : l'envoi direct est refusé, la fusion est immédiate. La protection s'adapte au dépôt, sinon elle se retourne contre celui qu'elle protège.

4. Sans « appliquer aux administrateurs », la règle est décorative #

C'est le piège le plus coûteux, parce qu'il est invisible. Sans cette case, la protection ne s'applique pas aux comptes administrateurs — c'est-à-dire précisément aux comptes qui poussent le plus. On croit avoir fermé la porte ; elle est ouverte pour ceux qui passent le plus souvent.

Ce que ça change pour vous #

Pour un client, cette décision n'est pas un détail d'organisation interne. Elle a trois effets directs :

• Rien ne peut plus partir en production sans que les tests soient passés avant. Auparavant ils tournaient après le départ : ils constataient, ils ne protégeaient pas.
• Chaque modification a une trace. Une demande de fusion porte un titre, une description, un résultat de tests et une date. C'est exactement ce qu'un audit — ou une certification — demande à voir, et ce qu'un historique d'envois directs ne fournit pas.
• L'accident d'envoi involontaire est devenu impossible. Ce n'est plus une question de vigilance individuelle, c'est un refus du serveur.

Et le coût de tout cela, pour l'équipe, est d'un clic supplémentaire par modification. C'est le meilleur rapport entre ce qu'on gagne et ce qu'on paie que nous ayons mis en place ce trimestre.