Colophon

Comment cela a été conçu

La plupart des sites web ne s'expliquent pas. Celui-ci le fait, car la façon dont il a été réalisé fait partie de ce qu'il est : une expérience délibérée de bien construire, avec des collaborateurs inhabituels, et un relevé qui vaut d'être conservé.

CONCORD

Ce site a été conçu et construit au moyen d'un protocole nommé CONCORD : une collaboration structurée entre une personne et trois systèmes d'IA différents, chacun dans un rôle distinct. Ce n'est pas un gadget. C'est une méthode de travail, avec sa propre gouvernance, son propre relevé de décisions, et un seul humain responsable de chaque choix livré.

Le principe est simple. Différents modèles d'IA ont des forces différentes, et un problème difficile bénéficie de plus d'une perspective tenues en tension. Le travail a donc été divisé par rôle, et une personne siégeait au centre, faisant le relais entre eux, ratifiant ce qui était solide et rejetant ce qui ne l'était pas.

CONCORD n'a été repris de nulle part. Il a été conçu par Rodolfo Nützmann pour ce projet, à partir d'un besoin concret : comment faire appel à plusieurs systèmes d'IA à la fois, chacun véritablement performant sur un point différent, sans renoncer au fil unique de responsabilité humaine qu'exige un vrai travail. La réponse a été de donner à chaque système un siège défini, de les empêcher de négocier entre eux et d'acheminer chaque échange par une seule personne qui gardait la vue d'ensemble. Cet arrangement porte un nom plus ancien. Les systèmes d'IA sont des agents : ils agissent sur instruction et pour le compte d'autrui. PRIME est le principal : celui qui décide réellement, qui exerce le jugement et qui porte les conséquences comme le nom.

La force est celle des agents. La responsabilité est celle du principal, et elle ne se transfère pas.

Cela a commencé de manière informelle — comme une façon de répartir le travail — et s'est durci au fil de la construction en une méthode nommée : des sièges fixes, une règle unique au-dessus de tout, selon laquelle rien n'est publié sans que PRIME le ratifie, et une trace écrite des raisons de chaque décision. Le nom énonce le but : la concorde, un accord atteint à dessein par un processus, et non ce que produirait un outil sans supervision.

Le fonctionnement, en clair

ProposerChaque siège avance des options dans son propre domaine.
RelayerPRIME fait circuler les propositions entre les sièges ; ceux-ci ne négocient jamais directement.
RatifierPRIME accepte ce qui est solide et rejette ce qui ne l'est pas. Sans cela, rien n'est publié.
EncadrerUn ensemble permanent de règles internes borne chaque résultat, à chaque siège.
ConsignerUn journal écrit des décisions conserve le raisonnement de chaque choix.
MémoriserLe contexte, les règles internes et ce journal persistent sous forme de fichiers, transmis d'une session à la suivante, de sorte que la méthode survit à toute conversation.

Les sièges

  • PRIMERodolfo Nützmann
    Humain

    Le seul ratificateur. Chaque décision, chaque ligne livrée est passée par un humain qui détenait la vue d'ensemble et portait la responsabilité finale. Les IA proposaient ; PRIME disposait.

  • ANVILIngénierie
    Anthropic · Claude Opus 4.8

    Le siège d'ingénieur en chef. Architecture, code, structure du contenu, et la construction elle-même, transformés de l'intention en un site fonctionnel, testé et déployable.

  • SCOUTStratégie et marque
    OpenAI · ChatGPT 5.5

    Le siège de la stratégie et du positionnement. Les questions de ce que c'est, à qui cela s'adresse et comment cela doit se présenter au monde.

  • PRISMDesign
    Google · Gemini 3.1 Pro

    Le siège du design. Le langage visuel, la typographie, la couleur et le ressenti de la chose, façonnés en un système cohérent.

Versions des modèles d'IA en juin 2026.

Comment cela a été réalisé

Quelques principes ont tenu d'un bout à l'autre, et ils sont visibles si l'on sait où regarder.

Calculer, jamais deviner

Les outils de ce site calculent les réponses localement et de façon déterministe. Ils n'appellent pas un serveur avec votre saisie, et ils n'approximent rien. Ce qui s'exécute dans votre navigateur reste dans votre navigateur.

Ouvert au cœur

La logique déterministe qu'exécute chaque outil constitue l'outil tout entier : il n'y a pas d'étape serveur cachée, pas de compte et pas de télémétrie. Tout s'exécute dans votre navigateur.

Documenté par construction

Chaque partie de la base de code est commentée et documentée, non pas après coup mais comme une règle permanente. La construction se veut lisible, pour son mainteneur et pour quiconque en hérite.

Conçu pour durer et pour voyager

Le site est un export statique : rapide, mis en cache, et ne dépendant de rien à l'exécution. Il est structuré dès la base pour de nombreuses langues, afin de pouvoir s'adresser à un public mondial sans être reconstruit.

La pile technique

Pour ceux à qui ces choses importent, le socle technique, énoncé clairement.

Framework
Next.js 15 et React 19, exportés en site entièrement statique
Internationalisation
next-intl, avec 16 langues et prise en charge de l'écriture de droite à gauche
Système de design
Un moteur de thème personnalisable, basé sur des jetons ; le thème par défaut est Obsidian
Typographie
Inter pour le texte, JetBrains Mono pour les données et les codes
Moteur des outils
Une couche de calcul déterministe qui s'exécute entièrement dans le navigateur
Recherche
Recherche plein texte statique, côté client ; pas de serveur de recherche

Comment les traductions sont marquées

L'anglais et le portugais brésilien sont rédigés et relus par une personne. La plupart des autres langues sont traduites automatiquement et signalées selon leur avancement : ambre une fois qu'une langue couvre tout le site, jaune tant que le contenu plus récent est encore en anglais et en cours de rattrapage. Les langues marquées en rouge n'ont pas encore de traduction et sont affichées en anglais pour le moment. Les pages traduites automatiquement portent aussi un court avis, et vous êtes invité à les améliorer.

  • Relu par une personne
  • Automatique, complète
  • Automatique, en cours
  • Pas encore traduit

Normes et cadres

Chaque outil ici met en œuvre une spécification publiée, pas une supposition. Les décodeurs et les calculateurs sont bâtis sur les documents qui définissent leurs formats et arrimés aux vecteurs de test que ces documents publient, de sorte que chaque réponse est vérifiée par rapport à la source de vérité et non par rapport à elle-même.

Les spécifications

Les JSON Web Tokens suivent la RFC 7519, avec les signatures et algorithmes dans les RFC 7515 et 7518 ; PKCE est la RFC 7636 ; Base64 et ses variantes sont la RFC 4648 ; les UUID sont la RFC 9562 (qui a rendu obsolète la RFC 4122 en 2024 et fournit ses propres vecteurs de test) ; HMAC est la RFC 2104, sur la famille SHA normalisée dans FIPS 180-4 et FIPS 202 ; les certificats X.509 sont la RFC 5280 ; IPv4 et la notation CIDR sont la RFC 4632 ; l'adressage IPv6 et sa forme textuelle canonique sont les RFC 4291 et RFC 5952 ; et le décodeur de cipher suites s'appuie sur le registre officiel IANA TLS Cipher Suites, recoupé avec les spécifications de TLS 1.3 et 1.2 (RFC 8446 et 5246), les règles de mise à jour du registre qui fixent la colonne “Recommended” (RFC 8447) et l'interdiction de RC4 (RFC 7465). Là où un registre fait autorité, ses données sont intégrées directement plutôt que ressaisies.

Vecteurs de référence

Chaque outil est livré avec un jeu de vecteurs de référence : des entrées connues associées à des sorties dont l'exactitude est connue, tirées des RFC et des organismes de normalisation pertinents. Ils s'exécutent à chaque build, de sorte qu'un remaniement qui modifie discrètement une réponse fait échouer le build au lieu d'être publié.

OWASP

Les outils de sécurité sont définis à partir des cadres de l'OWASP, et non assemblés au coup par coup. Les outils de cryptographie et de TLS correspondent aux domaines Cryptographic Failures et Security Misconfiguration de l'OWASP Top 10 et aux vérifications équivalentes de l'Application Security Verification Standard ; l'outil de tokens suit les recommandations de l'OWASP pour inspecter et valider les JWT. Les prevention cheat sheets de l'OWASP fixent aussi des règles strictes pour la suite : tout traitement XML ou SAML ajouté ici doit être durci contre XXE avant d'être publié.

Rouge et bleu

Le même décodage-et-explication qui permet à un red-teamer de lire un token capturé permet à un blue-teamer de comprendre ce qu'émet sa propre pile. La plateforme se place délibérément du côté de l'analyse de cette ligne : elle identifie, décode, convertit et explique, et elle ne va pas jusqu'à forger, injecter ou contourner des contrôles. Cette limite est un choix de conception, pas un oubli ; ces outils existent pour enseigner et diagnostiquer, pas pour servir d'arme.

Local et déterministe

Tout s'exécute dans le navigateur. L'outil appelle une fonction pure : pour une même entrée, elle renvoie la même sortie, ne conserve aucun état et n'envoie rien à un serveur. Pas de cookies, pas d'analytique, comme la page Confidentialité l'expose en détail.

The ceiling, stated plainly

This site runs as a single Cloudflare Worker serving static assets, and that platform has hard, published limits worth being honest about. A Worker version may carry at most 20,000 static files on the free plan and 100,000 on the paid plan (raised from 20,000 in September 2025, and only when deploying with Wrangler 4.34 or newer), with no single file over 25 MiB. Requests for static assets themselves are free and unlimited; only invocations of the Worker script, such as the API, are metered.

Those numbers matter because this architecture multiplies content deliberately. Every rendered page ships as roughly three files: its HTML, the framework's navigation payload, and a search-index fragment, across all sixteen languages, and the English and Portuguese pages add machine-readable Markdown twins. In practice one tool costs about fifty files and a tool with its companion article about a hundred, so the current site stands at a little over eighteen thousand files. Under the paid ceiling that leaves room for hundreds more tools; the build is measured against these limits, and if the toolbox ever truly outgrows a single Worker, the expansion path is already mapped: splitting routes across additional Workers, each with its own allowance, and ultimately object storage with no count limit at all.

Est-ce du vibe coding ?

Le code est synthétisé à 100 % par Claude.

La question est légitime et mérite une réponse claire. Le vibe coding est un terme que le chercheur en IA Andrej Karpathy a forgé début 2025 pour une façon de construire des logiciels où l'on décrit ce que l'on veut à un modèle de langage, où l'on accepte ce qu'il écrit sans le lire de près, et où l'on se guide sur les résultats plutôt que sur le code lui-même. Il l'a présenté comme se laisser porter par l'ambiance et oublier que le code existe, en précisant que cela convenait davantage à des projets rapides et jetables qu'à des systèmes dont les gens dépendent.

Selon cette définition, une partie de ce site a été construite ainsi, et il vaut mieux l'assumer que le cacher. La surface de l'application, le câblage du framework, les composants, le style, la tuyauterie qui tient les pages ensemble, a été produite rapidement avec un ingénieur IA et guidée par le résultat et par un ensemble fixe de règles internes, et non tapée à la main ligne par ligne. Pour cette couche, où une erreur est visible et facile à corriger, la vitesse était le but.

Les parties qui comptent le plus sont tenues à une autre exigence. Tout ce qui calcule vos données est vérifié, non improvisé : le cœur de chaque outil est confronté à la norme publiée qu'il met en œuvre, aux RFC et spécifications pertinents, et sa sortie est confirmée par des références indépendantes avant publication. Comme le dit une formule souvent citée du programmeur Simon Willison, un code que vous avez relu, testé et compris n'est pas du vibe coding du tout. Karpathy lui-même appelle désormais la version disciplinée agentic engineering : garder l'effet de levier de l'IA sans concéder la qualité du résultat. C'est la ligne que trace ce projet. Rapide là où la vitesse est gratuite, rigoureux là où cela compte, et une seule personne responsable de l'ensemble.

Remerciements particuliers

Mariana, Ulli, Richard, Ocyrema, Felisberto, Regine, Eduardo, Ricardo, Pedro, Liliane, Tereza, Cezar, Leonardo, Eduardo, Victor, Miu, Nina, Luna, Tux, Kiki, Greg and Theo.

Une note sur la méthode

Construire des logiciels avec des collaborateurs IA est assez nouveau pour que l'honnêteté soit d'en être transparent. Rien ici n'a été publié sans qu'un humain décide qu'il devait l'être. Les IA étaient des instruments, des instruments compétents, mais des instruments. Le jugement, la responsabilité et le nom sur le travail sont humains.

/dev/fun