Temps réel et complexité inutile

Réflexion technique sur l’usage du temps réel et son impact sur la complexité, la lisibilité et la durabilité des systèmes.

Les architectures temps réel sont devenues la norme dans de nombreux projets logiciels.
Applications connectées en permanence, mises à jour instantanées, synchronisation continue : la réactivité est souvent perçue comme un signe de modernité.

Dans certains cas, cette approche est parfaitement justifiée. Mais dans d’autres, elle introduit une complexité qui dépasse largement le besoin réel du système, comme expliqué dans Complexité utile et accidentelle .

Le problème n’est pas le temps réel lui-même.
Le problème apparaît lorsque le temps réel est appliqué à des problèmes qui ne le nécessitent pas.

Pourquoi tout rendre instantané ?

Aujourd’hui, de nombreux systèmes sont conçus avec une hypothèse implicite : tout doit être mis à jour immédiatement.

Une modification de donnée entraîne un recalcul instantané, une génération automatique ou une mise à jour en chaîne. Cette logique fonctionne bien pour des systèmes interactifs où l’utilisateur attend une réponse immédiate.

Mais tous les processus métier ne sont pas interactifs.

Lorsque ces processus sont forcés dans un modèle temps réel, le système devient progressivement plus difficile à comprendre.

La complexité invisible du temps réel

Un système temps réel accumule des états intermédiaires.

Une donnée est créée, modifiée, recalculée, corrigée, puis ajustée à nouveau. Chaque étape ajoute une couche logique supplémentaire, parfois implicite, parfois difficile à retracer.

Avec le temps, plusieurs questions deviennent difficiles à répondre :

• quel état a réellement produit ce résultat ?
• pourquoi ce calcul a-t-il changé ?
• quelle version des données était utilisée à ce moment-là ?

Le système continue de fonctionner, mais sa lisibilité diminue.

Ce phénomène n’est pas lié à la qualité du code.
Il est souvent lié au modèle choisi.

Ce type de choix architectural peut également contribuer à créer de la dette technique lorsque la complexité accumulée devient difficile à maîtriser.

Quand la réactivité devient un coût

Le temps réel apporte du confort immédiat, mais ce confort a un prix :

• dépendances plus nombreuses
• synchronisations permanentes
• gestion d’états complexes
• difficultés de reproduction d’un résultat passé

Dans des systèmes où la priorité est la traçabilité ou la reproductibilité, cette complexité peut devenir un obstacle.

Un système difficile à reconstruire peut aussi devenir plus difficile à maintenir.

Cette difficulté apparaît également dans certains problèmes backend , où les comportements imprévus deviennent plus difficiles à diagnostiquer et à corriger.

Pourquoi tous les systèmes n'ont-ils pas besoin du temps réel ?

Tous les systèmes n’ont pas besoin d’être instantanés.

Certains gagnent en clarté lorsqu’ils fonctionnent par étapes distinctes :

• préparation des données
• validation
• traitement
• production du résultat

Cette organisation par étapes rejoint également les principes utilisés dans les systèmes basés sur des API , où chaque échange doit rester clairement défini.

Cette séparation réduit les états intermédiaires et rend le système plus facile à comprendre au fil du temps.

Le choix entre le temps réel et le traitement différé n'est donc pas une question de modernité, mais d'adéquation au problème.

Simplicité et compréhension à long terme

Un système simple n’est pas un système limité.
C’est un système dont le comportement reste compréhensible après plusieurs mois ou plusieurs années.

Cette recherche de lisibilité constitue également un principe central du backend robuste , où l'objectif est de conserver un système fiable et maintenable dans le temps.

Dans de nombreux cas, la complexité apparaît non pas parce que le problème est difficile, mais parce que la solution choisie est plus rapide que nécessaire.

Le temps réel reste indispensable pour certains usages.
Mais lorsqu’il est appliqué par défaut, il peut transformer des problèmes simples en architectures difficiles à maintenir.

Comprendre le rythme réel d’un système est souvent la première étape pour le simplifier.

Lire l'article sur le backend robuste