01
Document
de référence
Doctrine Altisio.
Les dix principes qui gouvernent nos décisions. Ils sont indépendants des technologies, des offres et des missions.
Ce document s’adresse à qui veut comprendre ce qui survivra aux technologies, aux missions et aux personnes. Toute décision prise par la maison doit lui être compatible.
Document
- Version
- 1.0
- Adoptée le
- 10 août 2026
- Statut
- Active
- Portée
- Toute décision de la maison
- Référence
- DOCTRINE-01 à 10
02
Pourquoi
l’écrire
Une règle non écrite se plie au premier client difficile.
Toutes les entreprises ont des principes. Peu les écrivent, parce qu’écrire un principe revient à s’interdire quelque chose — et à rendre cette interdiction vérifiable par autrui.
C’est précisément l’objet de ce document. Il ne décrit pas nos intentions : il fixe ce que nous ne pouvons pas faire sans nous contredire publiquement.
Un principe qui n’interdit rien
n’est pas un principe.
03
Les dix
principes
Les principes.
Version 1.0 — dix entrées
-
01
Freedom by Design
Une bonne décision technique augmente toujours la liberté future de l’entreprise.
La liberté de faire évoluer un produit, de changer de partenaire, de recruter, de remplacer un outil, de grandir. Une architecture est réussie lorsqu’elle augmente les possibilités futures, pas lorsqu’elle démontre une sophistication.
-
02
Business before Technology
Chaque décision commence par le besoin, jamais par la technologie.
La question d’ouverture est toujours la même : quel est le besoin business ? La technologie est une conséquence de la réponse. Une décision qui commence par un choix d’outil est une décision prise à l’envers.
-
03
Understand before Build
Nous refusons de construire avant d’avoir compris.
Le métier, les utilisateurs, les contraintes, les équipes, l’histoire. Une mauvaise compréhension ne produit pas une architecture insuffisante : elle produit une architecture cohérente avec le mauvais problème.
-
04
Just Enough Architecture
L’architecture du prochain palier. Pas davantage.
Nous refusons autant la sous-conception que la sur-ingénierie. Une architecture doit répondre aux besoins d’aujourd’hui et préparer ceux de demain, sans anticiper inutilement ceux d’après-demain.
-
05
Decisions over Code
Le code change. Les décisions structurantes restent.
Les frameworks disparaissent, les outils évoluent. Nous documentons donc les décisions, pas seulement les implémentations. Le code n’est que la trace d’un raisonnement ; c’est le raisonnement qui a de la valeur.
-
06
Invisible Technology
La meilleure technologie est celle que l’on oublie.
Les utilisateurs ne devraient jamais avoir à penser au système, les équipes jamais subir leurs outils, les dirigeants jamais passer leur temps à gérer la technologie. Quand tout fonctionne, la technologie disparaît.
-
07
Transmission over Dependency
Une mission réussie réduit progressivement notre nécessité.
Notre objectif n’est pas d’être indispensables. Nous transmettons, documentons, expliquons, formons. Le code est un livrable ; l’autonomie est le résultat.
-
08
Calm Engineering
Nous refusons les effets de mode et les démonstrations techniques inutiles.
Nous privilégions une ingénierie lisible, compréhensible, évolutive, durable. Le meilleur système est celui qui inspire confiance, pas celui qui impressionne.
-
09
The Long View
Chaque décision est évaluée sur un horizon de plusieurs années.
Nous cherchons des solutions qui resteront pertinentes, et nous refusons les optimisations qui dégradent le long terme. La mode passe ; les principes restent.
-
10
Leave Things Better
Chaque intervention laisse le système dans un meilleur état qu’à notre arrivée.
Y compris pour une petite évolution, y compris lorsque personne ne le remarquera. C’est l’accumulation de ces écarts minimes qui produit, ou non, un système durable.
04
Ce qu’ils
impliquent
Un principe sans conséquence observable n’en est pas un.
Ce que la doctrine nous impose en pratique, et sur quoi un client peut nous tenir.
- Ce que nous ne vendons pas
- Du temps de développement au forfait, sans décision préalable. Conséquence de 02 et 03.
- Ce que nous disons toujours
- Le compromis d’une décision, avant qu’il ne se manifeste. Conséquence de 05 et 08.
- Ce que nous refusons
- Une architecture dimensionnée pour un palier hypothétique. Conséquence de 04 et 09.
- Ce que nous laissons
- Un registre de décisions que le client peut alimenter sans nous. Conséquence de 05 et 07.
- Ce que nous documentons
- Les options écartées autant que l’option retenue. Conséquence de 05.
- Ce qui met fin à une mission
- Le moment où notre présence n’ajoute plus rien. Nous le disons. Conséquence de 07.
05
Comment elle
se révise
Un document qu’on ne peut pas réviser est un document mort.
- Qui peut proposer
- Toute personne de la maison, et tout client engagé dans une mission en cours.
- Ce qu’exige une révision
- Une décision écrite et datée, exposant le principe visé, les options envisagées et la raison du changement. La procédure est celle que nous appliquons chez nos clients.
- Ce qui n’est pas révisable
- Rien. Un principe soustrait à la révision cesse d’être un principe pour devenir un dogme — ce que la doctrine interdit par ailleurs.
- Ce qui est conservé
- Les versions antérieures restent consultables. Un principe retiré est marqué comme tel, avec sa date et son motif. Rien ne disparaît en silence.
Journal des versions
-
v1.0
Adoptée le 10 août 2026
Version initiale. Dix principes, issus de la pratique des missions et non d’un exercice de formulation.