Principes d'ingénierie

Chaque projet commence par la compréhension du domaine — les contraintes physiques, le vocabulaire opérationnel, les modes de défaillance qui comptent. Pour un opérateur BESS, cela signifie comprendre ce que la dégradation du SOH coûte réellement en revenus de dispatch avant d'écrire la moindre requête. Pour un diffuseur, cela signifie comprendre pourquoi une seule image perdue à l'ingestion peut conduire à un paquet de livraison non conforme.

Nous ne considérons pas la connaissance du domaine comme un prérequis fourni par le client que nous consommons passivement. Nous y investissons nous-mêmes : en lisant les documents de standards, en réalisant des simulations et en posant les questions qui paraissent élémentaires — car ce sont souvent elles qui évitent des reprises coûteuses en fin de projet.

Il en résulte que nos estimations sont ancrées dans la réalité du domaine, et non dans des analogies optimistes avec des projets antérieurs. Lorsqu'un périmètre contient des incertitudes, nous les nommons explicitement plutôt que de les absorber silencieusement dans une marge de livraison.

Les systèmes complexes ne se simplifient pas d'eux-mêmes — cela exige une simplification délibérée à chaque couche d'abstraction. Nous considérons les décisions architecturales comme des artefacts de communication : une frontière de composant est une affirmation sur ce qui change indépendamment ; un modèle de données est une affirmation sur ce que le système doit savoir.

En pratique, cela signifie que nous résistons à la tentation de recourir à des frameworks qui résolvent des problèmes que nous n'avons pas encore. Lorsque nous ajoutons une dépendance, nous documentons pourquoi — et ce qu'il en coûterait de la retirer. L'objectif est une base de code dans laquelle l'ingénieur suivant peut comprendre l'intention à partir de la structure, et pas seulement des commentaires.

Les interfaces utilisateur portent la même obligation. Un tableau de bord qui nécessite une session de formation pour être compris sera ignoré dans les moments critiques. Nous concevons pour l'opérateur qui lit ces chiffres à 2 heures du matin — pas pour l'environnement de démonstration.

Un progrès non visible génère de l'anxiété, et l'anxiété produit des décisions prématurées. Nous partageons le travail en cours — pas des livrables peaufinés, mais des prototypes fonctionnels et des ébauches qui permettent au client de donner son avis avant que les investissements ne soient figés.

Lorsqu'une décision technique implique un compromis significatif, nous le rendons explicite plutôt que de présenter une conclusion toute faite. Lorsqu'une hypothèse de périmètre s'avère inexacte, nous le signalons immédiatement plutôt qu'ajuster silencieusement le calendrier de livraison pour compenser.

Cela s'applique également aux constats négatifs. Si une technologie que nous avons proposée s'avère inadaptée à mesure que nous en apprenons davantage, nous le disons. Le coût d'une correction précoce est presque toujours inférieur au coût d'une correction tardive.

La qualité du code est nécessaire, mais pas suffisante. Un module bien testé qui résout le mauvais problème, ou livré six semaines en retard, n'a pas créé de valeur. Nous traitons la fiabilité de livraison comme une métrique de qualité de premier ordre, au même titre que la couverture de tests et les benchmarks de performance.

Nous utilisons des pipelines CI/CD, des systèmes de types et des linters non pas parce qu'ils sont à la mode, mais parce qu'ils rendent le prochain changement moins coûteux. Nous écrivons des tests au niveau où ils sont les moins chers à maintenir et les plus susceptibles de détecter de vraies régressions. Nous profilons avant d'optimiser, et nous optimisons avant de réécrire.

Lorsque nous nous engageons sur une date de livraison, nous nous engageons sur le périmètre et les hypothèses sous-jacentes qui rendent cette date crédible. Si ces hypothèses changent, le calendrier est rouvert — et nous vous en informons immédiatement.

Les prototypes censés être remplacés le sont rarement. Lorsque nous construisons quelque chose qui fonctionnera en production, nous le traitons comme tel dès le premier commit : parité des environnements, logging structuré, error boundaries, dégradation gracieuse en cas de défaillance partielle.

Pour les systèmes temps réel, cela signifie réfléchir au backpressure avant la première connexion WebSocket. Pour les dashboards traitant de la télémétrie à grande échelle, cela signifie réfléchir au modèle de données sous charge avant que le premier graphique ne soit rendu. Pour les pipelines de streaming, cela signifie tester avec des débits binaires et des latences qui représentent les conditions réelles d'exploitation — et non des conditions de démonstration.

Nous ne demandons pas de sprint de nettoyage en fin de projet. Le coût de ce sprint est toujours supérieur à une attention répartie tout au long du projet, et le système qui en résulte est moins cohérent.

Un projet achevé n'est pas un résultat — c'est une étape. Le résultat, c'est un système qui continue à délivrer de la valeur à mesure que les exigences évoluent, que l'échelle change et que le domaine lui-même se transforme. Nous concevons pour cette trajectoire dès le départ : des points d'extension, un historique documenté des décisions et une passation qui laisse l'équipe du client réellement capable de continuer sans nous.

Nous préférons les clients qui nous considèrent comme un partenaire technologique à long terme plutôt que comme un prestataire de livraison. Non pour des raisons commerciales, mais parce que le travail est meilleur quand nous comprenons suffisamment le contexte métier pour remettre en question des spécifications qui créeront des problèmes dans douze mois.

Lorsqu'un projet se termine, nous considérons les connaissances accumulées comme un actif appartenant au client, pas à nous. La documentation, les diagrammes d'architecture et les runbooks font partie de chaque livraison.