Une entreprise qui construit dans plusieurs domaines s’expose à une objection raisonnable : l’étendue ne serait qu’un euphémisme pour l’absence de compétence particulière. La préoccupation est légitime, et elle mérite une réponse précise plutôt qu’un discours rassurant.
Les trois domaines dans lesquels nous construisons aujourd’hui ont très peu en commun sur le plan technique. Les logiciels et les plateformes numériques se confrontent à l’architecture, aux interfaces et à la longévité en conditions d’usage réel. L’intelligence artificielle et les données se confrontent à la propreté des entrées, à l’explicabilité des résultats et à des décisions qui parviennent à la personne en mesure d’agir. Le cloud et la cybersécurité se confrontent à la résilience, à l’identité et au coût d’une infrastructure mal conçue.
Domaines différents, architectures différentes, modes de défaillance différents. Rien n’est réutilisé de l’un à l’autre, sauf l’exigence.
L’exigence est une définition de ce qui est terminé
Ce qui se retrouve dans chaque système que nous construisons n’est ni une pile technique ni un framework. C’est la réponse à une seule question : ce qui doit être vrai avant que nous puissions dire qu’une chose est terminée.
Les domaines changent les détails de cette réponse, jamais sa substance. Dans chaque cas :
- Le problème est énoncé avant que la solution ne soit conçue.
- Le modèle de données et les frontières sont décidés avant l’interface.
- La sécurité et la performance sont des contraintes dès le premier commit plutôt qu’une phase ultérieure.
- Le système est suffisamment documenté pour qu’une personne qui ne l’a pas construit puisse le faire évoluer.
- Rien n’est livré parce qu’une date est arrivée.
Cette liste n’a rien de remarquable. Presque toutes les organisations d’ingénierie affirmeraient y adhérer. La différence ne tient pas au fait d’afficher cette exigence, mais à ce qui se passe lorsque la tenir devient coûteux, c’est-à-dire au seul moment où une exigence est réellement mise à l’épreuve.
Pourquoi l’exigence est la partie transférable
Il existe une asymétrie utile dans le logiciel. La connaissance d’un domaine est profonde mais étroite : comprendre le rapprochement comptable en entreprise n’apprend presque rien sur l’évaluation des modèles, et comprendre l’évaluation des modèles n’apprend presque rien sur la gestion des identités et des accès. Le jugement sur la manière de construire est large : il s’applique aux trois, et il se cumule.
C’est pourquoi nous organisons l’entreprise autour d’une méthode plutôt que d’un marché. Chaque nouveau domaine exige de tout apprendre depuis le début, et ce coût est inévitable. Ce qu’il n’est pas nécessaire de réapprendre, c’est la manière de décider, ce qu’il faut refuser, le moment où une conception n’est pas encore assez bonne, et quels raccourcis sont rattrapables.
Les trois domaines ne sont pas une revendication d’expertise sur tous les marchés. Ce sont les pratiques dans lesquelles nous construisons aujourd’hui, sous une même exigence d’ingénierie. Les champs plus larges restent une carte des lieux où le logiciel peut créer un avantage durable, pas une brochure de travaux déjà réalisés.
La profondeur garde l’étendue honnête
Le mode de défaillance d’une entreprise multi-domaines est évident : une collection de produits superficiels, dont aucun n’est assez bon pour compter, chacun privé de l’attention dont il avait besoin.
La parade est l’ordonnancement, et le nôtre est énoncé clairement : la profondeur avant l’étendue. Les systèmes actuels sont amenés à maturité et à une traction commerciale avant l’ouverture d’un nouveau front. Une croissance qui dépasse l’ingénierie est précisément l’échec que cette entreprise est conçue pour éviter, et on l’évite en refusant de commencer certaines choses plutôt qu’en essayant de les sauver plus tard.
Ce que cela donne vu de l’extérieur
Le plus souvent, cela ressemble à du calme. Une exigence correctement appliquée produit très peu de choses à annoncer : aucune réécriture à expliquer, aucun incident à analyser a posteriori, aucune migration à célébrer. Le résultat de bonnes décisions d’architecture, c’est l’absence d’événements.
C’est une chose difficile à communiquer, et nous l’acceptons. Les annonces ne sont pas des réalisations, et une entreprise discrète n’est pas nécessairement une entreprise inactive. La preuve d’une exigence ne réside pas dans ce que l’on en dit. Elle réside dans le fait que le logiciel soit encore bon dans cinq ans, et cette preuve met cinq ans à se constituer.