Table des matières

Rahul Garg nous parle de la phase design (conception) dans Design-First Collaboration.

Il nous parle de niveaux progressifs d’alignement de la conception avant tout codage, de réduction de la charge cognitive, de permettre de détecter les malentendus au moment le moins coûteux possible.

Ce serait pas de l’accessibilité numérique, un peu ça ?

Coder avec une IA, ça change quoi ?

Rahul Garg avant de commencer à coder commence par discuter, remettre en cause, se mettre d’accord… avec son collègue. Ils établissent le périmètre du projet. Son idée est de retranscrire une forme de réalité sur le tableau blanc.

Lorsque je programme en binôme avec un collègue sur un projet complexe, nous ne commençons pas par nous asseoir devant le clavier. Nous nous rendons d’abord au tableau blanc.

Nous esquissons les composants, discutons du flux de données, débattons des limites. Nous nous mettons d’accord sur ce que le système doit faire avant de discuter de la manière de le construire. Ce n’est qu’après cet accord que nous commençons à programmer.

Avec l’IA, tout va très vite, c’est séduisant. Elle comprends tout et semble tout coder vite et bien. Mais l’IA ne s’arrête pas trop pour discuter de la subtilité de la conception. Tout est décision.

Rahul Garg appelle le “piège de l’intégration” (Implementation Trap).

L’IA produit des résultats tangibles si rapidement que le point de contrôle naturel entre la réflexion sur la conception et l’écriture du code disparaît. Le résultat n’est pas seulement un code mal aligné. C’est aussi la charge cognitive liée au démêlage de décisions de conception pour lesquelles je n’ai jamais été consulté, regroupées dans une implémentation que je dois maintenant examiner ligne par ligne.

Rahul Garg et le coût du Design Invisible

Le piège de la mise en œuvre ne réside pas simplement dans le fait que l’IA ignore la conception. D’une manière significative, l’IA prend bel et bien des décisions de conception lorsqu’elle génère du code.

Je ne peux à aucun moment dire « attendez, nous avons déjà un système de file d’attente » ou « cette interface ne fonctionnera pas avec nos services existants ».

La première fois que je découvre la conception de l’IA, c’est lorsque je lis le code, ce qui est le moment le plus coûteux et le plus exigeant sur le plan cognitif pour découvrir un désaccord.

Designer ce serait : mettre en regard ce qu'on avait prévu et la manière dont c'est intégré dans le code.

Lorsque l’IA génère du code à partir d’une seule invite, le codeur évalue simultanément la portée, l’architecture , l’intégration, les contrats et la qualité du code — tout cela en même temps, de manière indissociable.

Cela représente trop de critères d’évaluation pour une seule lecture. Le cerveau n’est pas conçu pour cela.

Rahul Garg et le tableau blanc

Pour coder avec l’IA, Rahul Garg propose donc de reconstruire le tableau blanc. Plutôt que de demander directement la mise en œuvre, il passe par différents niveaux de conception.

5 Niveaux d’abstraction du tableau blanc
  1. Capacités — Que doit faire ce système ? Seulement les exigences essentielles, sans détails de mise en œuvre.
  2. Composants — Quels sont les éléments constitutifs ? Services, modules, abstractions majeures.
  3. Interactions — Comment les composants communiquent-ils ? Flux de données, appels API, événements.
  4. Contrats — Quelles sont les interfaces ? Signatures de fonctions, types, schémas.
  5. Mise en œuvre — Écrivez maintenant le code.

Avec ce tableau blanc, un modèle mental partagé se construit progressivement. Le Design-First applique la même discipline à la collaboration en matière d’IA : une conversation séquentielle où l’alignement se construit étape par étape, et où chaque étape limite l’espace de décision pour la suivante.

Quel rapport avec l’accessibilité ?

Rahul Garg nous parle d’alignement, il parle de la manière dont sa pratique du design First lui a permis (selon lui) de détecter les malentendus au moment le moins coûteux possible. Il parle donc d’une méthode axé sur l’efficience.

Il pense qu’avec l’IA, appliquer une méthode par étape pour vérifier l’alignement entre le Design et le code est toujours pertinente.

La version la plus simple de cette approche consiste en une seule contrainte : pas de code tant que la conception n’est pas approuvée. Tout le reste découle de là.

Si vous avez déjà entendu parlé de Shift Left en accessibilité (traiter les sujets d’accessibilité le plus tôt possible dans la chaîne de production), ce principe évoque la question de l’alignement du Design, du code, du contenu à chaque étape de la production.

L’empirisme nous montre que mettre en place une stratégie d’amélioration de l’accessibilité c’est : aligner.

Le groupe de pilotage définit la politique, le référent aligne les actions avec la politique… et les spécialistes alignent la chaîne de production avec les exigences en accessibilité.

L’article de Rahul Garg est très intéressant. Il va plus loin, car il montre bien que les actions de Vibe Coding devrait aussi être aligné avec les exigences d’accessibilité numérique.

Le problème, c’est déjà que les organismes ne sont pas très avancés sur les questions d’Accessibilité Numérique, donc pas de stratégie accessibilité au sujet des IA ; mais en plus, on a presqu’aucune littérature sur le sujet et, à ma connaissance, très peu d’expertise.