01.03 — KISS et complexité ostentatoire#
La critique reçue#
Le premier retour public reçu par Ocarina, systématique d’après l’auteur :
La première « critique » a souvent été la même : « Tu te vantes de quelque chose qui est très simple. »
Le Holy Book y répond longuement. Trois piliers : le caractère opérant de la simplicité, la distinction simple ≠ peu élaboré, et le refus de toutes les contre-propositions « créatives » reçues.
Simple ≠ peu élaboré#
C’est aussi pour cette raison que KISS (Keep it simple, stupid) est si mal compris dans l’industrie : beaucoup imaginent que « simple » signifie « peu élaboré ». Difficile de moins bien comprendre une théorie.
Ce qui est « simple » est le résultat d’un travail d’élaboration. C’est un état terminal, pas un état initial.
Les contre-propositions refusées#
L’article Premiers retours énumère, point par point, les contributions que d’autres « confrères » ont essayé d’imposer. Chacune est citée pour être refusée :
- Tordre l’implémentation de ROP (Railway Oriented Programming) d’Ocarina jusqu’à lui en faire perdre tout son sens, puisqu’ils ne savaient même pas ce que signifie ROP,
- Inclure des « hooks » et autres « techniques de ninja » en plein milieu des pas de test,
- Abandonner le typage,
- Tout réécrire en Rust pour la « performance »,
- M’imposer leur incompréhension de l’évaluation paresseuse et de l’IoC comme des vérités absolues,
- « M’expliquer » ce que sont la programmation impérative et déclarative en racontant n’importe quoi,
- Me « parler » d’event-driven programming, toujours en racontant n’importe quoi,
- Et pire que tout, me parler d’une horrifiante théorie d’« orienté objet déclaratif »,
- Etc.
Chacun de ces refus est documenté par un choix de design d’Ocarina :
| Refus | Choix Ocarina |
|---|---|
| « Tordre ROP » | Result[T], machine à états ActionStart → ActionFailure → ActionSuccess → ActionChain, Neutral* pour le rail d’échec. Strictement linéaire, ne peut pas être détourné. Voir ../02-ocarina/03-railway/02-action-chain-states.md. |
| « Hooks au milieu des pas de test » | Hooks confinés à create_act(on_failure=…, on_run_effect=…, act_counter_effect=…). Pas de hook global injectable. Voir ../02-ocarina/03-railway/05-create-act-hooks.md. |
| « Abandonner le typage » | mypy strict = true, ruff select = ALL, generics PEP 695 partout, pytest-mypy-plugins pour tester les types. Voir ../04-internal-tests/04-mypy-plugins-types.md. |
| « Réécrire en Rust » | Python pur. Le sujet du framework est la lisibilité et le vocabulaire métier, pas la performance brute qui ne dépend pas ici du langage utilisé pour l’orchestration. |
| « Incompréhension IoC / lazy » | Effect, Thunk, ChainRunner, validate(...).execute(), Watcher.callback : tout est paresseux, et l’IoC est documentée dans le code. Voir ../03-functional/. |
| « Orienté objet déclaratif » | @final partout ; pas d’héritage non contrôlé ; extension par composition (closures, adapters projet). |
Le compliment recherché#
Et si, en lisant un premier scénario de test, la réaction est « c’est super simple », il est dommage de penser le faire sur le ton de la critique : c’est exactement le compliment recherché. Merci.
Cette phrase est centrale : la simplicité du résultat est la métrique de qualité. Une métrique inverse « regarde comme c’est élaboré » est explicitement qualifiée de narcissisme dans le Holy Book :
Le narcissisme s’exprime à travers le fait de tout rendre honteusement compliqué dans l’unique but de dominer. Pas à travers l’acquisition de compétences et la simplification des process, puisque la finalité est le dysfonctionnement total : le chaos.
L’intolérance à l’échec, signal narcissique#
Le Holy Book introduit une catégorie clinique : l’intolérance à l’échec comme signature du narcissique en environnement de test.
On les reconnaît aussi face à leur intolérance à l’échec. Ils veulent systématiquement montrer à quel point, EUX, ont « pensé à tout ». Jamais de rouge avec un narcissique, que du vert, que du « prêt à partir en production ».
Ocarina prend le parti opposé : un échec documenté vaut mieux. C’est exactement la posture d’ocarina-with-ai-example qui conserve ses tests en échec sur les gaps de CURA (cf. ../08-ai-example/05-security-gaps.md) :
Anything red outside those categories is a real regression or a transient network error.
Et la règle est gravée dans le CLAUDE.md du projet IA :
Les tests gap sont reformulés, pas basculés au vert. Inverser l’assertion, renommer, déplacer la ligne dans le doc de stratégie, consigner la date dans
IDENTIFIED_GAPS.md.
La praticité comme objectif#
La conclusion de l’article :
Plutôt que de vouloir « faire des trucs de geeks », Ocarina propose de résoudre de petits problèmes sans en créer de plus importants. La conclusion qui en a été tirée est : « Ocarina est pratique ». C’est le but d’Ocarina : sa praticité.