Chaque fois qu'un incident est passé, on en a tiré une règle. Ces règles sont devenues notre doctrine interne. En voici le principe, et quelques-unes des plus importantes.

Il y a quelques années, après un incident qu'on aurait pu éviter, on a commencé à noter nos règles. Pas les règles de code, les règles de conduite. Pas « comment faire bien » « ce qu'on refait quand ça casse ». Aujourd'hui ces règles forment un document interne qu'on relit à chaque projet et à chaque recrutement. On l'appelle « nos 12 lois ».

C'est le genre de document qu'on ne montre pas aux clients habituellement, parce qu'il expose nos failles autant que notre méthode. On a décidé de le montrer, parce que c'est ce qui différencie une agence sérieuse d'une agence qui promet.

Pourquoi des « lois » et pas des « bonnes pratiques »

Les bonnes pratiques, c'est ce qu'on fait quand tout va bien. Les lois, c'est ce qu'on fait quand on est fatigué, pressé, ou tenté de couper un coin. La différence est fondamentale : une bonne pratique est une recommandation, une loi est une contrainte qu'on s'impose pour nous protéger de nous-mêmes.

Chaque loi vient d'un incident réel. On ne les a pas inventées en séminaire. On les a payées, souvent le soir ou le week-end.

Quelques-unes des plus importantes

« Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde. » On restaure pour de vrai, régulièrement. Si la restauration rate, on corrige avant la prochaine sauvegarde. Pas de « on verra en cas de besoin ».

« Une procédure non jouée est une hypothèse. » Chaque procédure critique (bascule, restauration, montée de version) est répétée par un humain avant d'être considérée comme opérationnelle. Si elle n'est jouée que la première fois en incident réel, elle rate.

« Le succès silencieux tue. » Un système qui marche sans alerter n'est pas sain, il est muet. On veut des alertes régulières qui disent « je fonctionne », pas seulement des alertes qui disent « je suis cassé ».

« Mesurer avant de corriger. » On ne modifie pas un comportement en production avant d'avoir mesuré ce qu'il faisait. Sinon on risque de corriger un symptôme et de casser une fonction qu'on n'avait pas vue.

« Une personne nommée répond. » Un bug signalé par un client n'est jamais traité par un ticket anonyme. Une personne nommée prend la main, signe la réponse, suit jusqu'à la clôture. Si c'est elle qui ne peut pas, elle le dit, nomme son remplaçant, et le remplaçant signe à son tour.

À quoi ça sert pour vous

Trois choses.

D'abord, ça vous donne un cadre vérifiable. Vous pouvez nous demander comment une de ces lois a été appliquée sur votre projet.

Ensuite, ça vous dit à quoi vous attendre. Un prestataire qui écrit ses règles est un prestataire qui ne les improvise pas en cours de route.

Enfin, c'est transférable. Si vous reprenez un jour la main sur votre outil, ou si vous passez à un autre prestataire, vous pouvez partir avec le document : ce sont des règles qui ne sont pas spécifiques à Yumea, elles sont valables chez n'importe qui.

Ce qu'on a vu sur le terrain

La loi « une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde » est née d'un incident en 2022 : une sauvegarde quotidienne fonctionnait depuis des mois, et le jour où on en a eu besoin, on a découvert que le format d'export était corrompu. On a réussi à récupérer les données autrement, sans perte client. Mais depuis ce jour, on teste la restauration tous les trimestres.

Questions fréquentes

On peut voir le document complet ? Oui, sur demande en avant-contrat, dans sa version anonymisée. On vous l'envoie pour que vous puissiez le lire avant de signer avec nous.

Vous ajoutez des lois ? Oui, après chaque incident significatif. Les lois ne sont pas gravées dans le marbre, elles évoluent, mais une loi écrite ne s'enlève pas facilement, parce qu'elle a été payée.

Vous voulez voir à quoi ressemblent nos lois concrètement avant de nous confier un projet ? On vous envoie un extrait anonymisé. Parlons-en →