Claude et Ralph : deux approches pour créer un DatePicker complexe avec l'IA en développement produit

L'histoire du DatePicker dans cet article compte moins pour elle-même que comme modèle d'un choix que fait aujourd'hui presque toute équipe produit : demander à un réseau de neurones d'esquisser vite une interface fonctionnelle, ou bâtir d'abord un système dans lequel l'IA écrit du code selon des règles prédéfinies. Avec un composant de calendrier accessible pour React, les auteurs montrent que le débat ne porte pas sur le modèle le plus intelligent, mais sur qui gère la complexité dans le processus : l'ingénieur ou le hasard.

Les auteurs appellent la première voie l'AI drafting (brouillon par IA). La logique est simple : on prend un prompt détaillé, fondé sur les recommandations de WAI-ARIA APG, et on le confie à un modèle comme Claude. On obtient un DatePicker presque terminé, qui couvre effectivement l'essentiel de la tâche au départ.

Mais surgissent ensuite des problèmes que l'on voit rarement dans une première réponse séduisante. Suivre la spécification à la lettre peut entrer en conflit avec le comportement des lecteurs d'écran réels, des gestionnaires comme onBlur et onClick se disputent et provoquent des défauts visuels, et les réglages fins d'accessibilité, par exemple le mode d'annonce des changements via aria-live, ne se devinent pas sans tests en conditions réelles. L'équipe se retrouve moins avec une architecture achevée qu'avec un bon brouillon, qu'il faut ensuite stabiliser à la main.

La seconde voie est l'ingénierie système. Ici, on ne donne pas à l'IA une consigne du type « fais un DatePicker » : on la place dans une boucle de production rigoureusement conçue. Les auteurs ont utilisé un agent autonome inspiré de l'approche Ralph, reposant sur codex cli et un petit modèle, mais l'élément décisif n'était pas le modèle, c'était l'environnement.

Dans le répertoire de travail de l'agent, ils ont déposé un PRD aux exigences figées, un ensemble de tâches atomiques dans tasks.json et des règles système interdisant de s'écarter de l'architecture cible. Parmi les conditions obligatoires : une API controlled-only, une navigation complète au clavier et un balisage ARIA correct.

Après chaque étape, le code passait par une boucle de vérification externe : tests unitaires et contrôles a11y avec Vitest et Playwright, build Vite et vérification des types TypeScript. Tant que la tâche en cours ne passait pas la vérification, l'agent ne pouvait pas avancer.

Ce dispositif change non seulement la discipline de développement, mais aussi la forme du code lui-même. Au lieu d'un composant monolithique, une structure à trois couches émerge peu à peu : un cœur pur contenant les dates et la logique de saisie, une couche UI distincte faite de composants aussi simples que possible, et une couche de liaison qui gère l'état et les interactions. Cela coûte plus cher au départ : il faut rédiger les exigences, décomposer le travail, configurer le vérificateur et dépenser davantage de tokens.

En contrepartie, le coût des modifications baisse avec le temps. S'il faut ajouter une fonction ou corriger un algorithme, les changements se font dans une couche précise plutôt que d'être dispersés dans tout le composant. Les auteurs montrent aussi honnêtement qu'une bonne architecture ne protège pas automatiquement : un petit changement dans le calcul des semaines a provoqué une défaillance en cascade, rappel qu'entre les couches, il faut des contrats explicites et une validation automatique.

L'observation la plus utile de l'article concerne le type d'erreurs. En mode brouillon par IA, les principaux défauts se logent aux jointures : événements, état, rendu, accessibilité, intégration de plusieurs morceaux de code apparemment corrects. Ils sont difficiles à repérer d'avance, et le débogage exige souvent de garder tout le composant en tête. Dans l'approche systématique, les erreurs descendent plutôt au niveau des fonctions et des modules individuels. Si le calendrier gère mal février d'une année bissextile, l'équipe ne cherche pas le problème dans toute l'interface, mais dans une seule fonction pure, que l'on peut isoler vite avec un test et corriger sans effets de bord.

D'où la conclusion pratique : le brouillon rapide convient aux MVP, aux prototypes, aux hackathons et aux utilitaires jetables, où la vitesse compte plus que la maintenance à long terme. L'approche systématique se justifie lorsque le composant fera partie d'un design system, du cœur d'un produit ou d'un projet appelé à durer.

Ce que cela change en pratique

L'IA sait déjà accélérer fortement la création d'interfaces, mais la principale bifurcation ne se situe pas entre les modèles, elle se situe entre les modes de travail des équipes. Si le coût d'une erreur est faible, on peut privilégier la vitesse et accepter la finition manuelle. Si le composant doit vivre longtemps et que d'autres développeurs en dépendront, il vaut mieux investir dans les exigences, les tests, les contrats et un processus qui limite la liberté de l'agent. L'étape suivante la plus réaliste est un hybride : concevoir le système selon des règles d'ingénierie et confier au réseau de neurones les tâches routinières et bien formalisées, à l'intérieur de ce cadre.