Dette technique contre dette opérationnelle : des systèmes qui fonctionnent, à terme

Les organisations d’ingénierie sont devenues plutôt douées pour parler de dette technique. Nous la mesurons, nous l’intégrons à des quality gates, nous négocions du temps pour la rembourser. Il existe une seconde forme de dette qui reçoit bien moins d’attention, alors qu’elle est souvent plus coûteuse : la dette opérationnelle, celle qui ne vit pas dans notre code mais entre nos systèmes, dans les processus qui les font tenir ensemble.

Pour décrire le comportement de la dette opérationnelle, je trouve utile d’emprunter un concept que tout ingénieur Kafka connaît : la cohérence à terme (eventual consistency). Beaucoup d’organisations reposent sur ce que j’appellerais des systèmes qui finissent par fonctionner. Le rapport mensuel part, le fournisseur est payé, le client reçoit une réponse. À la fin, à chaque fois. Mais seulement après une relance, un tableur, une correction manuelle et un collègue resté un peu plus tard que prévu.

Une petite note de vocabulaire, puisque « eventually » est un faux ami notoire. Il ne signifie pas éventuellement. Il signifie à terme, au bout du compte. Un système qui « finit par fonctionner » n’est pas un système qui fonctionne de temps en temps ; c’est un système qui finit toujours par fonctionner, à un prix que personne n’a mesuré. Ce prix est le sujet de cet article.

Deux dettes, deux grands livres

La dette technique et la dette opérationnelle sont liées, mais elles se comportent très différemment.

	Dette technique	Dette opérationnelle
Où elle vit	Dans le code et l’architecture	Dans les processus entre les systèmes et les équipes
Qui la remarque	Les ingénieurs, lors des évolutions	Les personnes qui font le travail, chaque jour
Comment elle est mesurée	Analyse statique, revues, métriques de delivery	Rarement, voire jamais
Qui paie les intérêts	L’équipe, par une delivery plus lente	Des individus, en temps, en attention et en soirées
Comment elle est remboursée	Refactoring et refonte	Refonte des processus et construction des outils manquants

Les deux s’alimentent mutuellement. Quand un système ne peut pas faire ce dont le métier a besoin, quelqu’un construit un contournement autour : un tableur, une vérification manuelle, une correction récurrente. La dette technique à un endroit devient de la dette opérationnelle partout autour.

Ce que promet réellement la cohérence à terme

Sa promesse est réputée modeste : si aucune nouvelle mise à jour n’est faite sur une donnée, toutes les copies finiront par renvoyer la même valeur. À aucun moment donné vous ne pouvez exclure un comportement incohérent, et la seule garantie est qu’à un moment dans le futur, quelque chose de bien se produira.

Pourtant, un grand nombre de produits à succès sont construits sur cette garantie. La raison n’est pas la garantie elle-même. C’est tout ce que les ingénieurs ont construit autour : mesurer à quel point les données sont réellement périmées, borner le temps de convergence, concevoir une compensation explicite quand les copies divergent, et choisir des structures de données qui ne peuvent pas entrer en conflit. La cohérence à terme fonctionne en production parce qu’elle est entourée de discipline.

La dette opérationnelle, vue comme un système distribué

Regardez une entreprise avec la même grille de lecture et la ressemblance est frappante. Les équipes se comportent comme des services. E-mails, messages de chat et réunions sont les messages qu’elles s’échangent. Le même client, le même contrat ou le même chiffre vit à plusieurs endroits à la fois : un système cœur, un CRM, un tableur, une présentation préparée pour le comité de jeudi. Ces copies divergent, et quelque chose doit les faire converger.

Dans un système bien conçu, ce quelque chose est un protocole. Dans une organisation qui finit par fonctionner, c’est une personne.

Système distribué	Organisation qui finit par fonctionner
Boucle de retry	Relancer quelqu’un par e-mail, puis par chat, puis dans le couloir
Dead-letter queue	Le tableur des exceptions dans la boîte mail de quelqu’un
Job de réconciliation	La vérification manuelle du lundi matin
Transaction compensatoire	La correction manuelle, parfois appliquée directement en base de données
Idempotence	Espérer que personne ne traite deux fois le même dossier
Consumer lag	Le backlog que personne ne mesure
Monitoring et alerting	Un collègue qui « sent bien » que quelque chose cloche

Chaque mécanisme de reprise que l’architecture a oublié est toujours là. Il a simplement été implémenté dans des personnes. C’est à cela que ressemble la dette opérationnelle de l’intérieur : la boucle de retry est une personne.

Pourquoi ce n’est pas de la cohérence à terme

Il serait réconfortant de conclure que les organisations ne sont qu’un système à cohérence à terme parmi d’autres et que tout va bien. La comparaison s’effondre précisément là où cela compte.

Elle n’a jamais été choisie. La cohérence à terme est un compromis délibéré, fait pour la disponibilité ou la performance. Un processus qui finit par fonctionner est ce qui reste quand un processus n’a jamais été conçu, seulement accumulé.
Elle n’est pas mesurée. Les ingénieurs suivent le consumer lag en secondes. Presque personne ne sait combien de temps prend en moyenne une demande client pour converger à travers trois équipes et deux tableurs, ni à quel point ce temps varie.
Elle n’est pas bornée. Un consommateur Kafka qui prend des heures de retard déclenche une alerte. Un dossier qui reste trois semaines dans une boîte mail ne déclenche rien jusqu’à ce qu’un client se plaigne.
Ses compensations sont improvisées. Une transaction compensatoire est conçue, testée et relue. Une correction manuelle est inventée sous pression et mémorisée, dans le meilleur des cas, par la personne qui l’a appliquée.
Sa convergence dépend de personnes précises. Un protocole de consensus ne part pas en vacances. Le collègue qui sait quel chiffre corriger dans le tableur du lundi, si.

Il y a aussi la question des mises à jour. La cohérence à terme ne promet la convergence qu’une fois les mises à jour arrêtées, et les organisations ne s’arrêtent jamais : de nouveaux produits, de nouvelles réglementations et de nouvelles exceptions arrivent chaque semaine. La dette opérationnelle a exactement cette qualité. L’organisation est toujours en train de converger et n’a jamais tout à fait convergé.

Enfin, les ingénieurs savent où la cohérence à terme ne doit pas être utilisée. Personne ne veut que deux distributeurs de billets croient, au même moment, que le même argent est encore disponible. Pourtant, les flux qui comptent le plus, comme les paiements, les engagements envers les clients et les chiffres réglementaires, sont très souvent ceux qui tiennent par une convergence manuelle.

Les intérêts de la dette opérationnelle

Les systèmes qui finissent par fonctionner fonctionnent bel et bien. C’est précisément ce qui rend leur dette si difficile à voir et si difficile à contester. Mais les intérêts sont réels, et ils se paient en trois monnaies.

La peine. Elle est payée d’abord par les personnes qui font converger : les interruptions, les soirées, le poids silencieux de savoir que si elles ne vérifient pas, personne ne le fera. Ce sont très souvent les personnes les plus consciencieuses de la maison.

Le coût. Chaque relance, chaque réconciliation et chaque correction manuelle est du temps qui aurait pu servir ailleurs. Parce qu’il est réparti sur de nombreuses personnes par petites tranches, il apparaît rarement dans un budget, et c’est exactement pour cela que l’on discute de la dette technique et pas de la dette opérationnelle.

Le risque. Les étapes manuelles sont là où se concentrent les erreurs, la fraude et la dépendance aux personnes clés. Les personnes ne sont pas idempotentes : sous pression, la même correction est appliquée deux fois, ou pas du tout. Les recherches sur les seuls tableurs donnent à réfléchir, des audits de terrain trouvant des erreurs dans la grande majorité des tableurs examinés. Et quand la personne qui fait converger un processus s’en va, la connaissance de la façon dont il converge part souvent avec elle.

La rembourser avec les leçons que nous avons déjà

Ce qui est encourageant, c’est que nous n’avons pas besoin d’une nouvelle discipline. Nous devons appliquer au second grand livre une discipline que nous maîtrisons déjà.

Mesurer à quel point c’est « à terme ». Bailis et Ghodsi décrivent comment la mesure de systèmes réels a montré qu’ils étaient cohérents bien plus souvent que leurs garanties faibles ne le laissaient penser. La dette opérationnelle mérite la même honnêteté : mesurez combien de temps une demande met à converger, et à quel point cela varie. Dans les environnements régulés, une piste d’audit bien conçue contient déjà l’essentiel du signal.
Borner la fenêtre. Décidez combien de temps « à terme » peut durer pour chaque flux, et levez une alerte quand ce délai est dépassé. Un « à terme » non borné n’est pas une conception, seulement un espoir.
Rendre les opérations idempotentes. Une correction qui peut être appliquée deux fois sans risque, liée à un identifiant de dossier, élimine toute une classe d’erreurs humaines.
Rendre la compensation explicite. Remplacez la correction improvisée par une correction documentée, outillée et relue. Si une compensation a lieu chaque semaine, ce n’est pas une exception ; c’est une fonctionnalité manquante, et une ligne dans le backlog de dette technique.
Savoir où ne pas être « à terme ». Pour l’argent, les engagements envers les clients et les chiffres réglementaires, investissez dans des garanties fortes plutôt que dans une convergence héroïque.
Sortir les personnes de la boucle de retry, et les garder pour le jugement. Les machines sont douées pour réessayer. Les personnes sont douées pour décider de ce que signifie un cas inhabituel. Les organisations qui finissent par fonctionner ont tendance à avoir ces rôles exactement inversés.

Remarquez que la moitié de ces leçons retransforment la dette opérationnelle en travail technique : une fonctionnalité à construire, un outil à fournir, une garantie à concevoir. C’est le vrai lien entre les deux grands livres. La dette opérationnelle est souvent de la dette technique qui n’a jamais été écrite, payée par mensualités par des personnes au lieu d’être remboursée une fois par un système.

Les personnes dans le protocole

J’aimerais terminer là où cette dette vit réellement. Les collègues qui font converger une organisation qui finit par fonctionner ne sont pas le problème à résoudre.

Sans eux, le rapport ne partirait pas et le client ne recevrait pas de réponse. Ils compensent discrètement des décisions de conception qu’ils n’ont pas prises.

La chose la plus bienveillante que nous puissions faire pour eux n’est pas de les remercier pour une soirée tardive de plus. C’est de mesurer ce qu’ils portent, d’intégrer la convergence dans le système, et de leur rendre leur temps pour le travail qui a réellement besoin d’un être humain.

Un système qui ne fonctionne qu’à terme fonctionne quand même, jusqu’au jour où la personne qui le fait converger est en vacances.

Ce qui change

Identifier et quantifier la dette opérationnelle est la première étape pour la rembourser.

Dans le prochain article, j’aborderai la façon dont l’ère agentique exigera un nouveau niveau d’excellence opérationnelle, avec plus que jamais le besoin d’améliorer continuellement le système, et l’importance d’une culture de l’écrit, de processus documentés et de responsabilités claires pour garder le système fiable.