Le design, c'est le code

Comment la logique des automates cellulaires va remodeler les systèmes de design agentiques, et pourquoi l'avenir du développement web est peut-être déjà écrit dans des règles simples

Une transformation profonde est en cours, à la croisée des systèmes de design, de l'intelligence artificielle et de la théorie du calcul. Un changement si fondamental qu'il remet en question ce que le mot « design » signifie encore à l'ère des agents autonomes.

Pendant des décennies, nous avons traité le design et le code comme deux disciplines distinctes : le design, domaine de la créativité humaine et du jugement esthétique ; le code, traduction mécanique de ces idées en une forme exécutable. Mais à mesure que des agents d'IA assemblent seuls des interfaces utilisateur, consomment les systèmes de design comme une infrastructure lisible par les machines et génèrent du code à partir de jetons sémantiques, nous approchons d'un point de convergence qui fait écho à une idée bien plus ancienne de la théorie du calcul.

Cette idée ? Le design, c'est le code.

Ce n'est pas qu'une formule accrocheuse. C'est le constat que nous nous dirigeons peut-être vers un monde où les systèmes de design fonctionnent comme des automates cellulaires : des règles simples qui donnent naissance à des comportements complexes et émergents. Un monde où la frontière entre « concevoir » quelque chose et le « programmer » disparaît complètement. Où les agents autonomes ne se contentent pas d'utiliser les systèmes de design, mais en sont l'incarnation en action.

Cet article de blog explore les liens profonds entre les automates cellulaires, le comportement émergent et l'avenir des systèmes de design agentiques. Nous retracerons les fondements théoriques, des machines autoréplicatives de von Neumann aux essaims d'agents d'IA d'aujourd'hui.

Nous verrons comment Drupal et les plateformes CMS modernes intègrent l'IA grâce à des modules comme Schema.org Blueprints et Drupal AI. Et nous nous demanderons ce que tout cela signifie pour les designers, les développeurs et l'avenir de la création de produits numériques.

Les automates cellulaires et la logique de l'émergence

La beauté des règles simples

En 1970, le mathématicien John Conway présentait le Jeu de la vie, un « jeu sans joueur » appelé à devenir l'un des systèmes les plus étudiés de la théorie du calcul. Ses règles sont d'une simplicité à couper le souffle :

1. Toute cellule vivante ayant moins de deux voisines vivantes meurt (sous-population)
2. Toute cellule vivante ayant deux ou trois voisines vivantes survit
3. Toute cellule vivante ayant plus de trois voisines vivantes meurt (surpopulation)
4. Toute cellule morte ayant exactement trois voisines vivantes devient vivante (reproduction)

De ces quatre règles, exprimées en une poignée de conditions binaires, naît un univers de complexité stupéfiant. Des planeurs traversent des grilles infinies. Des oscillateurs pulsent selon des rythmes perpétuels. Des canons projettent des flots de motifs à travers l'espace cellulaire. Et, plus remarquable encore, il a été démontré que le Jeu de la vie est Turing-complet : tout ce qui peut être calculé algorithmiquement peut, en principe, l'être dans la simple grille de Conway.

Figure 1 : le canon à planeurs de Gosper dans le Jeu de la vie de Conway. Ce motif produit un flux continu de planeurs, et montre comment des règles simples peuvent engendrer une complexité infinie qui s'entretient d'elle-même.

Voilà la première leçon des automates cellulaires : la complexité n'est pas une condition préalable aux comportements complexes. Des règles simples, appliquées de façon uniforme sur un substrat, peuvent donner naissance à des motifs et à des comportements que personne n'a explicitement programmés.

Les boucles de Langton et l'autoréplication

En 1984, Christopher Langton a poussé ce principe plus loin avec ses boucles autoréplicatives, un automate cellulaire qui illustrait de véritables principes de vie artificielle. Là où le Jeu de la vie de Conway montre une complexité émergente, les boucles de Langton font apparaître une reproduction.

émergente. Chaque boucle est formée d'une frontière cyclique qui enferme un « génome » codé dans les états des cellules. Ce génome circule en continu autour de la boucle puis le long d'un bras de construction, qui édifie une boucle fille en 151 pas de temps. Une fois celle-ci achevée, la fille se détache de sa mère, et toutes deux poursuivent leur réplication.

Figure 2 : la boucle de Langton dans sa configuration initiale. L'information génétique circule dans la boucle et dirige la construction des boucles filles grâce au bras qui s'allonge.

« Si une machine capable de se reproduire est possible au sein d'un automate cellulaire, alors la vie elle-même pourrait être à la portée des machines. »

- Christopher Langton, « Studying Artificial Life with Cellular Automata » (1986)

Les implications sont profondes. Les boucles de Langton montrent que l'autoréplication n'exige ni la complexité des cellules biologiques ni les capacités de construction universelle du modèle original de von Neumann. Il suffit de :

• Un ensemble de règles simples et locales
• Un mécanisme pour encoder des instructions
• Un processus par lequel ces instructions sont exécutées

Les règles sont l'organisme. Le plan est le code.

En 1999, Hiroki Sayama a introduit les evoloops, des variantes qui intègrent la dissolubilité structurelle et des interactions phénotypiques, rendant possibles des mutations spontanées et une dynamique évolutive. Ces boucles évoluent par des collisions physiques directes pendant la réplication, ce qui entraîne des variations de génotype, une diversité morphologique accrue et une complexité croissante au fil des générations. Contrairement à la réplication figée de Langton, les evoloops présentent des mutations héréditaires sans aucune intervention extérieure.

La règle 110 et le calcul universel

L'exploration des automates cellulaires élémentaires par Stephen Wolfram a abouti à une découverte stupéfiante : la règle 110, l'une des 256 règles possibles pour le type le plus simple d'automate cellulaire unidimensionnel, est capable de calcul universel.

La règle 110 peut être définie entièrement en donnant le résultat pour chacune des huit combinaisons possibles d'une cellule et de ses deux voisines. Pourtant, cette règle d'une simplicité désarmante, soit huit décisions binaires, peut simuler une machine de Turing universelle.

Figure 3 : l'automate cellulaire de la règle 110. Malgré sa définition simple, la règle 110 présente un comportement de classe 4 (des motifs complexes, ni tout à fait stables ni tout à fait chaotiques) et il a été prouvé qu'elle est Turing-complète.

« Pas besoin d'un processeur d'ordinateur complet pour faire du calcul universel. Il suffit de cette petite règle. »

- Stephen Wolfram, « A New Kind of Science »

En 2004, Matthew Cook a publié une preuve que la règle 110, associée à un certain motif de fond répétitif, est Turing-complète. La preuve montre que la règle 110 peut émuler des systèmes d'étiquettes cycliques, qui peuvent à leur tour émuler n'importe quelle machine de Turing. Parmi les 88 automates cellulaires élémentaires uniques possibles, la règle 110 est la seule dont la Turing-complétude ait été directement prouvée.

Le principe d'équivalence computationnelle proposé par Wolfram suggère quelque chose de plus radical encore : les systèmes qui dépassent un seuil minimal de complexité sont essentiellement équivalents dans leurs capacités de calcul. Un cerveau humain, un système météorologique et la règle 110 sont, en un sens profond, équivalents sur le plan computationnel.

La métacellule 0E0P : la véritable auto-réplication

En octobre 2018, Adam P. Goucher a achevé la construction de la métacellule 0E0P, un motif du jeu de la vie de Conway capable de véritable auto-réplication. Contrairement aux métacellules précédentes, qui nécessitaient des copies préexistantes à proximité, la métacellule 0E0P peut construire des copies d'elle-même à partir de zéro, y compris sa propre bande d'instructions.

Cette réalisation marque une étape importante de la vie artificielle : un système capable de se propager dans un substrat computationnel en n'utilisant que des règles locales. Le 23 novembre 2013, Dave Greene a construit le premier réplicateur du jeu de la vie qui crée une copie complète de lui-même, bande d'instructions comprise, démontrant que même l'automate à deux états, pourtant simple, de Conway peut soutenir une auto-reproduction sans limite.

Les systèmes de design comme substrats computationnels

De l'Atomic Design au design agentique

La méthodologie Atomic Design de Brad Frost, présentée en 2013, a révolutionné notre façon de penser les systèmes de design. En décomposant les interfaces en atomes (éléments de base comme les boutons et les champs de saisie), molécules (combinaisons simples), organismes (sections d'interface complexes), gabarits (mises en page) et pages (réalisations finales), l'Atomic Design offrait une structure hiérarchique pour maîtriser la complexité.

Mais voici ce qui est remarquable avec le recul : l'Atomic Design incarnait déjà les principes des automates cellulaires sans les reconnaître explicitement.

« Quand le design system est ennuyeux, il libère les designers et les développeurs pour qu'ils s'attaquent à la nouveauté, à de nouveaux problèmes. Le design system porte le fardeau de l'ennuyeux, pour que designers et développeurs n'aient pas à le faire. »

- Josh Clark, « The Most Exciting Design Systems Are Boring »

En février 2023, Brad Frost écrivait à propos des « Design Systems in the Time of AI » :

« L'IA est une consommatrice naturelle des design systems... Le fait est qu'une grande partie du travail sur les composants d'un design system est en réalité mécanique et prévisible. Nous utilisons déjà des outils comme PlopJS pour générer d'un coup le squelette d'un composant qui épouse la forme du reste de la bibliothèque. J'accueillerais volontiers l'aide de l'IA pour produire à ma place un grand nombre de ces éléments de base courants. »

- Brad Frost

C'est précisément le caractère mécanique et prévisible des design systems qui les rend propices à un fonctionnement de type automate cellulaire. Quand les règles sont claires, locales et appliquées de façon constante, les agents peuvent agir en autonomie, tout comme les cellules du Jeu de la vie de Conway n'ont besoin d'aucun contrôleur central pour produire des planeurs et des oscillateurs.

L'impératif de la lisibilité par les machines

L'initiative Storybook MCP (Model Context Protocol) représente une évolution décisive dans cette direction. Annoncé fin 2025, Storybook MCP fournit aux agents de code IA des métadonnées de composants lisibles par les machines, tirées des configurations Storybook existantes.

L'idée clé, c'est que les agents n'ont besoin ni de code brut ni de documentation visuelle. Il leur faut :

• Des manifestes de composants : des métadonnées structurées sur chaque composant : ses props, ses variantes, ses liaisons avec les design tokens et des exemples d'utilisation
• Un nommage sémantique : des tokens riches d'intention, comme action.primary.confirm, qui donnent du sens aux agents au lieu de leur transmettre de simples valeurs
• Des boucles de validation : la capacité d'exécuter des tests, de voir les échecs et de se corriger seuls

« Storybook MCP aide les agents à suivre vos conventions et à passer vos tests. Il leur donne deux choses qu'ils n'avaient jamais eues : des métadonnées de composants lisibles par les machines et une boucle itérative pour corriger eux-mêmes leurs erreurs. »

- L'équipe Storybook

Storybook MCP intègre une boucle de correction autonome. Elle permet aux agents d'exécuter les tests de vos composants (interaction et accessibilité), de voir ce qui échoue et de corriger leurs propres bugs. Le développeur n'intervient qu'une fois les tests passés. Fini le baby-sitting de prompts.

C'est exactement l'architecture d'un automate cellulaire appliquée au design : des règles locales (les spécifications des composants), des interactions de voisinage (les modèles de composition) et des mises à jour itératives (validation et autocorrection).

Mon manifeste de composant comme génome

La comparaison avec les boucles de Langton devient encore plus pertinente quand on regarde comment fonctionnent les manifestes de composants. Dans le système de Langton, le « génome » encodé dans les cellules qui circulent contient les instructions pour construire une nouvelle boucle. Dans un design system lisible par les machines, le manifeste de composant contient les instructions pour assembler les interfaces.

Un manifeste de composant pourrait préciser :

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

Ce manifeste est à la fois une spécification de design et du code exécutable, ou plutôt les instructions à partir desquelles du code exécutable peut être généré. L'agent qui consomme ce manifeste n'a pas besoin de comprendre l'esthétique ni l'expérience utilisateur au sens humain. Il doit suivre les règles, combiner les éléments selon leurs contraintes et produire des sorties valides.

Je suis d'accord avec Brad Frost sur l'idée d'utiliser un format YAML.

Les composants Drupal utilisent déjà le format YAML. Quelque chose comme

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

Le design est le code.

• Variantes
• Jetons
• Props

• Contraintes (que l'on pourrait ajouter aux composants)

• Règles des slots (ce qui peut être placé dans d'autres slots, ou ce qui est autorisé dans mon slot)

• Règles

• Exemples 

• Animations  ( Autorisées ou recommandées )

Ensuite, observez et expérimentez le comportement.

comme dans https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Les design tokens comme variables d'environnement

Les design tokens forment une autre pièce essentielle du puzzle. Dans les automates cellulaires, les cellules réagissent à leur environnement immédiat, c'est-à-dire à l'état des cellules voisines. Dans les design systems, les composants réagissent aux design tokens, ces valeurs contextuelles qui déterminent leur apparence et leur comportement.

Les architectures de tokens modernes reposent sur plusieurs couches :

• Tokens de base : Valeurs brutes comme color.blue.500: #3B82F6
• Tokens sémantiques : Références guidées par l'intention, comme color.action.primary: color.blue.500
• Tokens de composant : Applications ciblées, comme button.background.primary: color.action.primary

Quand un agent génère un composant Button, il n'a pas besoin de savoir que « primary » veut dire bleu. Il lui suffit de faire référence à button.background.primary et de se fier au système de tokens pour résoudre la bonne valeur. L'environnement (la couche de tokens) contient l'information ; le composant (la cellule) n'a qu'à y réagir.

Des outils comme Tokens Studio ont évolué pour traiter les design tokens comme des graphes de calcul dotés de résolveurs, des nœuds qui prennent des décisions sémantiques sur les tokens de base à utiliser selon le contexte. Les design tokens passent ainsi de simples valeurs statiques à des systèmes dynamiques fondés sur des règles.

L'écosystème Drupal et l'intégration de l'IA

Intégrer l'IA aux systèmes de gestion de contenu (CMS), c'est disposer d'un laboratoire idéal pour explorer les principes de « le design, c'est le code ». Des CMS comme Drupal incarnent déjà les concepts de base : types de contenu structurés, définitions de champs, relations et règles de composition.

Je n'aurais jamais pensé qu'on puisse dire une chose pareille. Pour moi, c'était le summum de la technique.

 L'ordinateur ultime dont on pourrait rêver. Des développeurs qui sembleraient venus du futur de Star Trek, parlant à l'ordinateur pour qu'il programme à leur place.

L'expérience agent (AX) et le nouvel utilisateur

Concevoir pour les machines

Début 2025, Mathias Biilmann, PDG de Netlify, a introduit le concept d'« expérience agent » (Agent Experience, AX), une nouvelle discipline centrée sur la manière dont les agents d'IA interagissent avec les produits et les plateformes.

Le changement est fondamental. Pendant des décennies, l'UX (expérience utilisateur) a été optimisée pour la cognition, la perception et le comportement humains. La DX (expérience développeur) l'a été pour les développeurs humains qui construisent des logiciels. L'AX part du constat que les agents deviennent des utilisateurs de premier plan des systèmes numériques, et que leurs besoins sont tout autres :

• Ils ne se soucient pas de l'esthétique visuelle, seulement de données structurées et analysables
• Ils ne naviguent pas dans les interfaces, ils appellent des API et consomment des manifestes
• Ils ne lisent pas la documentation comme les humains, ils ont besoin d'un contexte lisible par les machines
• Ils ne portent pas de jugements subjectifs, ils suivent des règles et des contraintes

« Les agents d'IA ne sont pas des personnes : ils se moquent de la taille d'un bouton, de la lisibilité d'une typographie, de la belle palette de couleurs de votre site ou des animations tape-à-l'œil de votre application. Alors, de quoi les agents d'IA se « soucient »-ils ? C'est une question qui n'a pas de réponse concrète aujourd'hui, mais qui deviendra de plus en plus importante dans les années à venir. »

- Recherche AX

La réponse : des règles claires, des comportements prévisibles, des données bien structurées et des boucles de rétroaction qui leur permettent de vérifier et de corriger leurs actions.

Le défi de la double interface

Concevoir pour l'AX, c'est construire deux interfaces en même temps :

1. Interface humain-agent : là où les humains supervisent, approuvent, modifient et guident le comportement des agents : la couche de « contrôle de mission ». Pensez tableaux de bord et files d'approbation, pas formulaires et boutons.
2. Interface agent-système : là où les agents interagissent avec les API, les bases de données et les outils : la couche « opérationnelle ». Elle doit être robuste, bien documentée et optimisée pour l'efficacité des machines.

Cela reflète l'architecture des automates cellulaires, où deux perspectives distinctes coexistent :

• La perspective locale : chaque cellule (agent) suit des règles simples fondées sur ses voisines immédiates
• La perspective globale : des motifs complexes émergent, visibles seulement à grande échelle

« La conception de l'expérience des agents (AX) doit offrir une excellente utilisabilité pour les agents et par les agents. Ainsi, une excellente AX conduit à une excellente expérience utilisateur (UX). Si l'agent d'IA rencontre un processus ou un protocole défaillant, ou même des termes incohérents d'un système à l'autre, il est incapable d'accomplir sa tâche. C'est une mauvaise expérience pour l'agent, qui se traduit à son tour par une mauvaise expérience pour le client ou l'employé. »

- Kat Holmes, Chief Experience Officer, Salesforce

De l'UX à l'AX : l'évolution du design numérique

Stigmergie et communication indirecte

L'un des concepts les plus puissants de l'intelligence en essaim est la stigmergie : une coordination indirecte par les traces laissées dans l'environnement. Les fourmis ne se communiquent pas directement l'emplacement de la nourriture ; elles déposent des pistes de phéromones que les autres suivent. L'environnement devient un moyen de communication.

Dans les systèmes de design agentiques, la stigmergie prend la forme suivante :

• Bibliothèques de composants partagées : les agents « voient » quels composants existent et comment ils ont été utilisés
• Design tokens : des valeurs sémantiques qui encodent les décisions de design comme des faits de l'environnement
• Documentation des patterns : des exemples d'usage qui servent de pistes de phéromones aux futurs agents
• Suites de tests : des règles de validation qui délimitent l'espace des résultats valides
• Historique Git : une trace des décisions passées que les agents peuvent consulter

Quand un agent génère une interface avec un composant, il laisse des traces : dans la base de code, dans la documentation, dans les patterns qu'il établit. Les agents suivants, confrontés à des tâches similaires, seront influencés par ces traces, ce qui crée une forme d'intelligence collective qu'aucun agent ne possède à lui seul.

Patterns de design agentiques

Andrew Ng et d'autres ont identifié quatre patterns clés pour les systèmes d'IA agentiques :

1. Réflexion : l'IA évalue sa propre production et l'améliore de façon itérative
2. Utilisation d'outils : l'IA interagit avec des outils, des API et des systèmes externes
3. Planification :L'IA décompose les tâches complexes en sous-tâches et les exécute l'une après l'autre
4. Multi-agents : Plusieurs agents spécialisés collaborent sur des tâches complexes

Ces schémas correspondent directement aux concepts des automates cellulaires :

Le design, c'est le code : une lecture plus approfondie

Ce que « le design, c'est le code » veut vraiment dire

Quand nous disons « le design, c'est le code », nous avançons en réalité plusieurs affirmations à la fois :

1. Équivalence sémantique

Une fois correctement encodées, les décisions de design deviennent exécutables. Un jeton de design (design token) n'est pas une simple valeur : c'est une instruction. Une spécification de composant n'est pas qu'une documentation : c'est un programme. Quand les agents consomment ces artefacts, ils exécutent le design autant qu'ils l'implémentent.

2. Capacité générative

Tout comme la Règle 110 peut calculer tout ce qui est calculable, un système de design suffisamment complet peut générer n'importe quelle interface valide. Le système contient en puissance toutes ses expressions valides. Ce qui en émerge ne dépend que des conditions initiales (les exigences) et des règles (les contraintes).

3. Complexité émergente

Les interfaces les plus sophistiquées ne sont pas conçues de haut en bas : elles émergent de l'application cohérente de règles simples. Un bouton bien conçu, utilisé avec constance, produit un langage visuel cohérent sans que personne ait planifié cette cohérence de façon explicite.

4. Irréductibilité computationnelle

Certains résultats de design ne peuvent pas être prédits sans faire réellement tourner le système. Impossible de savoir à quoi ressemblera une interface assemblée par un agent sans le laisser l'assembler. C'est le principe d'irréductibilité computationnelle de Wolfram appliqué au design.

5. Automodification

Comme les evoloops qui mutent pendant leur réplication, les systèmes de design prêts pour les agents peuvent évoluer à l'usage. Les composants générés par les agents rejoignent la bibliothèque que les futurs agents consommeront. Le système apprend, s'adapte et grandit.

La métaphore des automates cellulaires, prolongée

Au-delà de la métaphore : une convergence bien réelle

Mais ce n'est pas qu'une métaphore. La convergence est réelle, et elle se produit maintenant :

• Storybook MCP transforme les bibliothèques de composants en instructions lisibles par les machines, que les agents exécutent
• Model Context Protocol standardise la façon dont les agents accèdent aux outils et au contexte, créant un substrat universel pour les opérations agentiques
• Les architectures multi-agents répartissent le travail entre des agents spécialisés (architecte, développeur, relecteur) qui interagissent selon des protocoles, comme des cellules aux fonctions différenciées
• Boucles d'autoréparationAutorisent les agents à exécuter des tests, à détecter les erreurs et à itérer : les mêmes mécanismes de rétroaction que les automates cellulaires utilisent pour faire évoluer des configurations stables
• Schema.org Blueprints rendent les structures de contenu lisibles par les machines et porteuses de sens
• Drupal AI fournissent l'infrastructure permettant aux agents d'IA de créer, modifier et gérer du contenu de façon autonome

Nous n'abordons pas « le design, c'est le code » comme une posture philosophique. Nous en faisons une infrastructure technique.

Implications et suite du chemin

Pour les designers

Le rôle du designer passe de « créateur de rectangles » à « définisseur de règles ». Comme l'a observé Brad Frost :

« Les designers et les développeurs qui voient leur métier comme de la création de rectangles ont de quoi s'inquiéter. Mais ceux qui voient leur métier comme la résolution de problèmes, et qui doivent au passage créer ou manier quelques rectangles pour les résoudre, ont moins à craindre. »

- Brad Frost

Dans l'avenir agentique, les designers :

• Définiront des tokens sémantiques et leurs relations
• Établiront des contraintes de composition et des modèles
• Créeront des règles de validation que les agents devront satisfaire
• Feront évoluer et entretiendront les règles qui gouvernent l'émergence
• Concevront les mécanismes de rétroaction qui permettent l'autocorrection
• Façonneront les « fonctions d'aptitude » (fitness functions) qui déterminent quels résultats sont acceptables

C'est du design à un niveau d'abstraction supérieur : concevoir les règles qui produisent les designs plutôt que les designs eux-mêmes. Comme définir les règles d'un automate cellulaire plutôt que dessiner chaque cellule une à une.

Pour les développeurs

Les développeurs deviennent les architectes de systèmes d'agents. Comme le décrit Anthropic :

« Le domaine du développement logiciel a montré un potentiel remarquable pour les fonctionnalités à base de LLM, avec des capacités qui ont évolué de la complétion de code à la résolution autonome de problèmes. »

Les développeurs devront :

• Créer des interfaces lisibles par les machines entre les agents et les systèmes
• Concevoir des boucles de rétroaction et des mécanismes de validation
• Construire l'échafaudage au sein duquel le comportement émergent peut se produire
• Garder la supervision humaine comme arbitre final
• Définir les protocoles par lesquels les agents communiquent
• Mettre en œuvre le « code de liaison » (glue code) qui relie les différents systèmes d'agents

Pour le développement web et les plateformes CMS

L'intégration de l'IA dans des plateformes comme Drupal annonce un avenir où :

• Les modèles de contenu deviennent consommables par les agents grâce à des standards comme Schema.org
• Les flux éditoriaux deviennent assistés par des agents avec une rédaction, une modération et une optimisation pilotées par l'IA
• La recherche évolue de la correspondance par mots-clés à la compréhension sémantique grâce aux embeddings et aux bases de données vectorielles
• La personnalisation devient autonome : les agents apprennent les préférences des utilisateurs et adaptent le contenu en temps réel
• Le développement s'accélère puisque les agents génèrent composants, tests et documentation

L'adoption de l'IA par l'écosystème Drupal, à travers des modules comme Drupal AI, Drupal Canvas, Schema.org Blueprints et l'intégration des fournisseurs d'IA, montre que cet avenir est déjà en construction.

Pour les organisations

L'avantage concurrentiel reviendra aux organisations dont les design systems sont les plus « prêts pour les agents ». Un système prêt pour les agents se caractérise par :

• Une couverture complète des états et des variantes des composants
• Un nommage sémantique qui exprime l'intention
• Une documentation et un contexte lisibles par les machines
• Une infrastructure de validation et de test
• Des contraintes claires qui délimitent l'espace des résultats valides
• Des API conçues pour être consommées par des agents (AX-first)
• Des architectures de contenu fondées d'abord sur Schema.org

Pour l'avenir des produits numériques

L'état final ressemble à une écologie numérique : d'innombrables agents qui obéissent à des règles locales et produisent des interfaces émergentes qu'aucun designer ni développeur n'a planifiées, mais qui, d'une manière ou d'une autre, forment un tout cohérent parce que les règles sous-jacentes sont solides.

Ce n'est pas aussi farfelu qu'il y paraît. C'est précisément ainsi que fonctionnent les systèmes biologiques, que les villes grandissent, que les marchés tournent. La question n'est pas de savoir si nous arriverons à cet état, mais comment nous négocierons la transition.

Conclusion : le code est vivant

John von Neumann, le polymathe qui a inventé les automates cellulaires, était mû par une question fondamentale : Quelle est la complexité minimale requise pour l'auto-reproduction ? Sa réponse, le constructeur universel de von Neumann, a démontré que l'auto-réplication n'exige aucune mécanique biologique. Elle exige seulement des règles qui encodent leur propre application.

Soixante-dix ans plus tard, nous découvrons que le même principe vaut pour les design systems. Pour générer une interface de façon autonome, il n'est pas nécessaire de disposer d'une intelligence artificielle générale ni d'une créativité de niveau humain. Il suffit d'un ensemble de règles complet, cohérent et lisible par une machine, que des agents peuvent exécuter.

Quand les boucles de Langton se répliquent sur une grille cellulaire, nous ne disons pas que les boucles « conçoivent » de nouvelles boucles. La réplication est simplement ce que produisent les règles. Pourtant, le résultat, des colonies toujours plus vastes de motifs auto-similaires, est indéniablement génératif, créatif dans un certain sens fonctionnel.

Quand des agents d'IA assemblent des interfaces à partir des composants d'un design system, en suivant des tokens sémantiques et des contraintes de composition, ils font quelque chose de comparable. La « créativité » ne réside pas dans les agents mais dans les règles qu'ils exécutent : des règles que les humains ont conçues, mais qui fonctionnent désormais de manière autonome.

Nous sommes au seuil d'une nouvelle ère de la création numérique. Les agents sont là. Les protocoles prennent forme. Les design systems deviennent des substrats pour la vie artificielle.

Le design, c'est le code.
Et le code prend vie.

Articles et projets clés

• Design Systems in the Time of AI - Brad Frost
• Storybook MCP Sneak Peek - Storybook
• Introducing AX: Why Agent Experience Matters - Mathias Biilmann
• Building Effective Agents - Anthropic

Ressources Drupal AI

• Drupal AI

• Module Schema.org Blueprints

   

Ressources sur les automates cellulaires

• Conway's Game of Life Lexicon - Environ 1 500 figures
• A Working Turing Machine in Game of Life
• Langton's Loops - Wikipedia
• Rule Sets for Cellular Automata
• A New Kind of Science Online - Stephen Wolfram
• Cellular Automata - Nature of Code

Exploration d'idées à la croisée de la théorie du calcul, des design systems, de l'intelligence artificielle et du développement web.

 Les points de vue exprimés sont des explorations spéculatives de tendances émergentes, et non des prédictions d'avenirs certains.

Je constate que nous créons des agents d'IA qui travaillent en boucle et interagissent avec d'autres agents d'IA dans des boucles supplémentaires.

Le design est le code lorsque le système fonctionne en boucle, comme une boucle de vie, dans un canevas et selon un ensemble de règles choisis.