Cette semaine, j’ai publié six articles. Un sur PostgreSQL. Un autre sur l’intelligence artificielle et ses agents. Un sur la gestion du contexte. Un tutoriel sur l’automatisation. Une analyse de debugging. Et enfin un design de conseil adversarial pour évaluer les MVPs.
Rien n’était planifié. Chaque article découle d’un article scientifique, une conférence ou un projet que j’ai trouvé intéressant indépendamment. Mais en les regardant collectivement, un fil conducteur apparaît, que je n’avais pas perçu en les écrivant.
Tous les six disent la même chose.
Le motif que je n’avais pas cherché
Tout a commencé avec l’article de Bohan Zhang sur comment OpenAI fait évoluer PostgreSQL. La conclusion était brutale : 800 millions d’utilisateurs, un seul primary, aucun sharding. PgBouncer (2007). Read replicas (un concept des années 90). La technologie la plus banale de la planète, toujours performante dans une des applications les plus utilisées de l’Histoire.
Cela a continué avec Michael Bolin démystifiant les entrailles des coding agents. Codex CLI, Claude Code — peu importe. En interne, il s’agit essentiellement d’une boucle while enveloppant un LLM. Pas de graphes de connaissance. Pas de planificateurs symboliques. Une boucle, des outils, et un modèle qui décide quand s’arrêter. La magie se résume à un simple while True.
Puis sont arrivés les articles Cookbook d’OpenAI sur l’ingénierie du contexte. La gestion de ce que le modèle voit est plus importante que le modèle en lui-même. Et les techniques sont déjà bien connues : injecter du contexte au démarrage (un README), découper l’historique (un buffer circulaire), compresser les anciens éléments (un résumé). Rien que des systèmes classiques de chat des années 2000.
Le tutoriel d’automatisation enfonce le clou : les Automations de Codex d’OpenAI se résument à cron + curl + un LLM. Littéralement. Le scheduler Unix le plus simple exécutant le modèle le plus avancé du moment. L’infrastructure a 40 ans. Le cerveau 2.
Puis les deux articles qui ne portent pas directement sur l’infrastructure. Le puzzle de Jane Street où un réseau neuronal de 2 500 couches s’est avéré être MD5. Résolu grâce à du debugging classique : observer les données, réduire le problème, accumuler des contraintes jusqu’à ne laisser qu’une solution. Les outils étaient nouveaux (SAT solvers, ChatGPT). Mais la méthode elle-même était ancienne (élimination systématique des hypothèses).
Enfin, le conseil adversarial pour les MVPs : simuler cinq experts fictifs avec un LLM pour évaluer des idées avant de les construire. Cela semble futuriste, jusqu’à ce qu’on réalise que c’est un wargame. Les militaires en font depuis les années 50. Les équipes produit appellent cela des pré-mortems. La nouveauté est que maintenant, ce panel coûte 2 dollars en tokens au lieu de 50 000 en consultants.
La thèse (qui n’est pas de moi)
Je ne dis rien d’original. Dan McKinley le dit depuis 2015 dans sa conférence “Choose Boring Technology”. DHH le répète chaque fois que quelqu’un propose Kubernetes pour un CRUD. Fred Brooks l’écrivait déjà en 1975 en affirmant qu’il n’existe pas de solution miracle.
Mais cette semaine, six exemples indépendants illustrent cela dans différents domaines.
| Domaine | Ce qui est “banal” mais fonctionne | Ce qui est “nouveau” et promet plus |
|---|---|---|
| Bases de données | PostgreSQL + PgBouncer | BDD distribuée avec sharding |
| Agents IA | boucle while + outils | Architecture multi-agent avec orchestrateur |
| Gestion du contexte | YAML + README + buffer circulaire | RAG avec stockage vectoriel + pipeline d’embed |
| Automatisation | cron + bash + curl | Plateforme d’orchestration cloud-native |
| Debugging | Observer → réduire → hypothèses → vérifier | Solutions d’interprétabilité intégrales |
| Évaluer des idées | Discussions structurées avec frameworks publiés | Plateforme de market research avec panels |
À gauche : ce que les véritables praticiens utilisent pour résoudre de vrais problèmes. À droite : ce qui est saupoudré aux conférences techniques.
Pourquoi cela arrive-t-il ?
Ce n’est pas que les nouvelles technologies soient mauvaises. Elles répondent simplement à des problèmes que la majorité des équipes n’ont pas.
OpenAI n’a pas besoin de sharding, car son modèle d’accès est composé à 95 % de lectures. Un seul primary peut gérer toutes les écritures, car ils ont pris le temps d’identifier les tâches lourdes pour les déplacer ailleurs. Ce n’est pas sexy. C’est comme couper au scalpel.
Les coding agents n’ont pas besoin d’architectures complexes, car le modèle est déjà assez performant pour choisir, dans une boucle simple, quel outil utiliser et quand s’arrêter. La complexité d’un orchestrateur est inversement proportionnelle à l’intelligence du modèle.
cron n’a pas besoin de substitut, car 99 % des automatisations se résument à “exécuter cela toutes les N heures”. Si votre automatisation demande plus — event sourcing, reprise d’erreurs, retry avec backoff — alors oui, il vous faut autre chose. Mais la majorité n’en a pas besoin. Et ce qui est inutile finit par peser.
Le piège du concepteur
Il existe un biais cognitif qui explique pourquoi nous continuons à chercher l’outil magique. On l’appelle complexity bias : la tendance à préférer des solutions complexes plutôt que simples, car les solutions complexes semblent plus adaptées à des problèmes difficiles.
Si votre base de données est lente, la solution “déplacer les écritures lourdes ailleurs” ressemble à un bricolage. La solution “implémenter le sharding avec un hash cohérent et un rebalancement automatique” ressemble à de la vraie ingénierie. Et, en tant qu’ingénieur, on préfère les solutions qui paraissent impressionnantes.
Mais le bricolage qui marche vaut mieux que l’ingénierie qui n’aboutit pas.
OpenAI aurait pu consacrer six mois à déployer le sharding. À la place, ils ont déplacé quelques workloads vers Cosmos DB et consacré ces six mois à créer des fonctionnalités pour leurs 800 millions d’utilisateurs.
En clair : le coût d’opportunité d’une solution élégante est l’autre solution que vous ne construisez pas dans l’intervalle.
Ce que cela implique pour vous
Ce n’est pas que vous ne devriez pas apprendre de nouvelles technologies. Mais avant de les adopter, posez-vous la question :
Quel problème ai-je que la technologie banale ne résout pas ?
Si la réponse est “aucun, mais la nouvelle est plus tendance”, vous ajoutez une complexité sans bénéfice. Et la complexité finit toujours par se payer. En bugs, en temps d’onboarding, en nuits de garde.
Si la réponse est “j’ai besoin de X que PostgreSQL ne permet pas” — parfait. Adoptez la nouveauté. Mais soyez spécifique sur ce qu’est X.
Puis-je résoudre cela avec ce que j’ai actuellement et un peu de discipline ?
OpenAI a résolu leur goulot d’étranglement des connexions avec PgBouncer. Ils n’ont pas changé de base de données. Ils n’ont pas réécrit leur couche d’accès à données. Ils ont simplement mis un connection pooler devant. La discipline, c’était : diagnostiquer le vrai problème, pas celui que l’on veut résoudre par ego technique.
Suis-je en train de résoudre un problème réel ou un problème futur ?
“La mise à l’échelle ne tiendra pas” est une des phrases les plus chères en ingénierie logicielle. Parce que c’est presque toujours vrai — rien n’est extensible à l’infini. Mais en pratique, 99 % des projets échouent avant d’avoir besoin de monter en charge. Et les 1 % qui survivent auront les ressources pour résoudre ça à temps.
La discipline n’est pas glamour
C’est toujours satisfaisant d’utiliser une base de données distribuée écrite en Rust avec son propre protocole de consensus. Cela fait bonne impression en conférence. Ça brille sur un CV.
Mais si tout ce qui est nécessaire est PostgreSQL avec un connection pooler et des requêtes bien conçues, la base distribuée est un coût inutile et sans avantage. Ce coût n’est pas seulement technique — il est attentionnel. Chaque heure passée à configurer votre cluster est une heure que vous ne passez pas à comprendre vos données, optimiser vos requêtes, ou interagir avec vos utilisateurs.
La discipline ennuyeuse — des requêtes simples, des timeouts agressifs, l’isolation des workloads, des scripts cron, des READMEs maintenus à jour, du debugging méthodique — ne fait pas les gros titres des keynotes. Pas de logo. Pas de conférences dédiées.
Mais c’est ce qui fonctionne quand tout le reste échoue.
Et cette semaine, six articles indépendants me l’ont rappelé en même temps. Parfois, le fil conducteur apparaît tout seul. Il suffit de savoir où regarder.
Les six articles de la semaine :
- OpenAI fait évoluer PostgreSQL pour 800M utilisateurs avec un seul writer — La base éprouvée qui tient là où les nouvelles échouent.
- Ton AI coding agent est une boucle while avec des délires de grandeur — Décryptage de Codex CLI et Claude Code.
- Le skill invisible de l’ingénierie du contexte — Ce que le modèle “voit” est plus important que le modèle lui-même.
- Codex Automations sans Codex — cron + bash + LLM = agents nocturnes.
- Un réseau neuronal de 2 500 couches qui s’avère être MD5 — Debugging classique appliqué au ML.
- Cinq experts fictifs examinent ta startup — Débat adversarial comme outil décisionnel.