Design engineering avec l’IA

Le design engineering, c’est le travail entre une maquette et le logiciel livré. Pendant des années, cela voulait dire remettre une image et espérer qu’elle survive au développement. Avec des agents de code IA, un designer peut décrire l’intention, laisser l’agent écrire le code, et juger le résultat là où ça compte : dans le navigateur, sur un téléphone, avec de vrais états.

La vitesse est réelle, le risque aussi. Un agent écrit du code plausible aussi vite que du bon code. Le métier passe du dessin à la direction et à la vérification.

Cinq règles que je donne à chaque agent de code, quel que soit le projet.

--one-set-of-instructions

Tous les agents que j’utilise lisent les mêmes instructions et les mêmes compétences : mes principes produit, mes règles de design, mes règles de sécurité. Changer d’outil ne veut pas dire repartir de zéro.

--small-verified-steps

De petits changements, chacun vérifié dans le navigateur et enregistré, plutôt qu’une grosse réécriture vérifiée à la fin.

--never-trust-the-output

Tout ce qu’un modèle renvoie est validé : données vérifiées contre un schéma, délai et solution de repli sur chaque appel, prompts versionnés comme du code.

--design-checks-in-the-loop

Un contrôle de design et une relecture critique passent avant toute livraison, pour que la vitesse ne glisse pas vers des interfaces génériques.

--test-like-a-user

Partir de l’écran où les gens arrivent vraiment, puis le clavier, le téléphone, les états vides et d’erreur. Jamais une URL raccourcie ni des données préparées.

Kawi

Kawi apprend le luxembourgeois aux enfants. Je l’ai conçu et développé avec des agents de code IA : l’application mobile, son site et ses vidéos. C’est un vrai produit avec de vrais utilisateurs, le seul test honnête d’une façon de travailler.

Ce site

Ce site a été conçu et construit de la même façon. Le portrait à côté de ce texte est parti d’une photographie ; les poses tournées et le casque ont été générés, détourés sur ma propre machine, puis imprimés en caractères par un petit script. La page passe un contrôle de design avant chaque mise en ligne.

Le point de départ n’est plus toujours une maquette à transmettre. Je peux construire une première version fonctionnelle, la tester dans le navigateur, vérifier les interactions et ajuster les détails avant même d’impliquer un développeur.

Cela change la nature de la collaboration. J’arrive avec quelque chose qui fonctionne déjà, mais aussi avec des questions plus précises. Le développeur peut se concentrer plus tôt sur ce qui demande son expertise : l’architecture, les données, la sécurité, la robustesse et l’intégration dans le système existant.

Le code généré n’est pas une livraison en soi. C’est un point de départ concret pour discuter, tester et décider ensemble.

Un prototype peut sembler parfaitement fonctionnel tout en reposant sur de mauvaises hypothèses. C’est justement l’intérêt de cette approche : rendre les problèmes visibles plus tôt, quand ils sont encore faciles à corriger.

Un agent peut produire du code propre en apparence, réussir le scénario principal et échouer dès que les conditions changent. Il peut mal gérer un état d’erreur, oublier un contrôle d’accès ou introduire une incohérence dans une partie du produit qui semblait sans rapport avec la modification.

Je vérifie le résultat dans le navigateur, je teste les parcours réels et je demande des changements progressifs. Mais ces vérifications ne remplacent ni une revue de code approfondie ni une validation de l’architecture.

Je passe la main à un ingénieur dès que le problème dépasse le périmètre que je peux vérifier sérieusement : sécurité et autorisations, migrations de données, concurrence, intégrations complexes, performance à l’échelle ou changements structurels dans le système.

Mon objectif n’est pas de remplacer l’expertise technique. C’est de pouvoir aller plus loin par moi-même, d’explorer davantage de solutions et d’arriver avec un problème mieux compris, un prototype testable ou une hypothèse déjà éprouvée.

La vitesse n’a de valeur que si l’on sait ce qui a été vérifié, ce qui reste incertain et à quel moment il faut faire appel à une autre expertise.

• steven-lozach(1), qui je suis et ce que je fais
• ai-designer(7), le métier, au Luxembourg
• kawi(1), le luxembourgeois pour les enfants