Object Calisthenics à l'ère de l'IA : un contrat enfin tenu

Les Object Calisthenics, formalisées par Jeff Bay et popularisées en français par William Durand, ont dix-huit ans. Leurs neuf règles sont enseignées en kata, affichées en poster, citées en onboarding. Et dans la plupart des équipes, elles finissent par être « généralement respectées » ; ce qui veut dire appliquées quand on y pense, contournées sous la pression d’un sprint.

L’IA générative change quelque chose là-dedans. Pas parce qu’elle est plus rigoureuse que les développeurs, mais parce qu’elle est sans fatigue, sans contexte de sprint et sans mémoire des exceptions passées. Passée en custom instruction, une règle d’Object Calisthenics devient un contrat machine : elle s’applique sur chaque ligne générée, sans négociation implicite.

En résumé — Les Object Calisthenics, pensées comme exercice pédagogique, fonctionnent comme contraintes de génération pour les agents IA. GitHub Copilot (via .github/copilot-instructions.md) et Claude Code (via CLAUDE.md) permettent de les formaliser en instructions persistantes. Le bénéfice : une cohérence structurelle du code généré sur la durée, indépendante du jour, de l’heure et de la charge de l’équipe.

Pourquoi les Object Calisthenics résistent si mal à la pression du quotidien ?

Les neuf règles ne sont pas difficiles à comprendre ; elles sont difficiles à maintenir collectivement dans le temps. Ce n’est pas un problème de motivation. C’est un problème de charge cognitive : appliquer consciencieusement neuf contraintes structurelles en même temps qu’on résout le problème métier, c’est épuisant. Les règles finissent par être internalisées comme un idéal plutôt que comme un contrat strict.

Dans les équipes que j’accompagne sur la stratégie d’outillage de développement, je vois systématiquement le même pattern : les règles de qualité sont écrites dans un wiki, portées par un ou deux seniors, et progressivement érodées par le turnover et les délais. Pas par mauvaise volonté ; par entropie naturelle. Le développeur qui rejoint l’équipe en cours de sprint n’a pas le temps d’internaliser les neuf règles avant de livrer sa première PR.

La revue de code attrape une partie des violations. L’outillage statique (ESLint, SonarQube) en couvre certaines ; pas toutes. Les Object Calisthenics portent sur des propriétés de design que les analyseurs statiques ne vérifient pas : l’encapsulation d’une primitive, le respect de la Loi de Déméter, la limite de deux variables d’instance par classe.

Que change réellement une custom instruction dans un agent IA ?

En 2025, selon le Stack Overflow Developer Survey, 84 % des développeurs utilisaient ou prévoyaient d’utiliser des outils IA dans leur workflow. Ce que cette adoption ne mesure pas encore bien, c’est la qualité structurelle du code généré sur la durée ; c’est précisément là qu’interviennent les custom instructions.

Quand on passe une règle à un agent IA sous forme d’instruction persistante, quelque chose de structurellement différent se produit : l’agent ne la pondère pas selon le contexte. Il ne fait pas l’arbitrage entre « la règle dit X, mais ici c’est plus pratique de faire Y ». Il applique.

La propriété clé des règles d’Object Calisthenics, c’est leur lisibilité machine : contrairement à « écris du code propre » ou « suis les principes SOLID », chaque règle est précise et vérifiable. « Un seul niveau d’indentation par méthode » peut être audité. « Pas d’abréviation » peut être checké sur un identifiant. Ce sont des contraintes de structure, pas des jugements de valeur : c’est exactement ce dont un modèle de langage a besoin pour les honorer de façon fiable.

GitHub Copilot supporte les custom instructions de dépôt via .github/copilot-instructions.md. Claude Code utilise CLAUDE.md à la racine du projet. Pour les équipes qui ont déjà intégré les agents IA dans leur workflow de développement, c’est une évolution directement applicable à l’outillage existant.

Comment intégrer les neuf règles dans CLAUDE.md et Copilot ?

Code sur fond sombre — geralt / Pixabay

La forme condensée ci-dessous s’installe directement dans CLAUDE.md ou dans .github/copilot-instructions.md. La densité compte : une instruction trop verbeuse est partiellement ignorée ; une trop vague l’est complètement. Neuf règles en neuf lignes, chacune avec une indication de violation, donnent suffisamment de signal sans surcharger le contexte.

## Object Calisthenics

1. Un seul niveau d'indentation par fonction — extrais une méthode dès qu'une boucle contient une condition.
2. Pas de `else` — utilise le early return ; traite les cas d'erreur en premier.
3. Encapsule les primitives avec comportement — crée un type dédié si une string ou un number porte de la logique métier.
4. Collections de première classe — une classe qui contient une collection ne contient que ça.
5. Un seul appel chaîné par ligne — Loi de Déméter.
6. Pas d'abréviations — noms complets et lisibles sans contexte.
7. Entités petites — max 150 lignes par fichier, max 10 fichiers par dossier.
8. Max deux variables d'instance par classe.
9. Pas de getters/setters pour décider à l'extérieur — Tell, don't ask.

C’est la section que j’utilise dans le CLAUDE.md de mes propres projets. La spécificité des règles les rend directement exploitables par un agent : aucune ambiguïté, aucun jugement de valeur à interpréter.

Object Calisthenics et revue de code : des niveaux complémentaires

Passer les règles en custom instruction ne rend pas la revue de code inutile ; elle en change la nature. Quand le code généré respecte structurellement les neuf règles, la revue se concentre sur ce qui ne peut pas être formalisé : la pertinence métier, les choix d’architecture, les edge cases non anticipés.

C’est un gain net. La revue ne se perd plus sur des remarques de structure que tout le monde connaît mais que personne ne veut formuler au dixième sprint. Pour les équipes qui travaillent avec une gestion de source rigoureuse, les règles appliquées systématiquement par l’IA réduisent également le bruit dans les diffs : des PR plus petites, des changements plus ciblés, des discussions de revue qui portent sur ce qui mérite vraiment d’être discuté.

Chaque règle bien libellée dans une custom instruction devient un reviewer silencieux qui ne saute aucune PR, ne se fatigue pas et n’a pas de mauvaise journée.

Questions fréquentes

Les Object Calisthenics s’appliquent-elles à tous les langages de programmation ?

Oui. Les neuf règles sont agnostiques au langage : elles portent sur la structure, l’encapsulation et la séparation des responsabilités, pas sur la syntaxe. Formalisées en Java par Jeff Bay, elles s’appliquent aussi bien en TypeScript, Python, Go ou Kotlin. Un agent IA adapte son interprétation au langage du fichier en cours d’édition, ce qui rend les instructions portables entre projets hétérogènes sans modification.

Est-ce que l’IA respecte vraiment ces contraintes de façon fiable ?

Pas à 100 %, et ce n’est pas l’objectif. Une instruction persistante augmente significativement la conformité sur le code généré, mais un agent IA peut produire des violations sur des cas complexes ou ambigus. La valeur n’est pas dans la perfection ; c’est dans la cohérence par défaut qui déplace la charge de la vigilance constante vers la revue ciblée des cas non triviaux.

Quelle est la différence entre Object Calisthenics et les règles ESLint ou SonarQube ?

L’outillage statique couvre des règles vérifiables mécaniquement : longueur de ligne, complexité cyclomatique, nommage par regex. Les Object Calisthenics couvrent des contraintes de design qui nécessitent une compréhension du code : encapsulation des primitives, Loi de Déméter, collections de première classe. Les deux sont complémentaires : les linters vérifient après l’écriture ; les custom instructions guident la génération en amont.

Faut-il réécrire le code existant pour se conformer aux règles ?

Non. Les custom instructions s’appliquent au code généré ou modifié par l’agent, pas à l’existant. C’est précisément l’intérêt : le codebase évolue progressivement vers la conformité, fichier par fichier, sans migration massive. Le code le plus critique peut être ciblé en priorité avec un agent mandaté sur une tâche de refactoring délimitée.