💻 computer science

Jas: AI-Paired Engineering as a Revival of N-Version Programming

Cet article présente une étude de cas démontrant que l'ingénierie couplée à l'IA, lorsqu'elle est ancrée par une spécification exécutable précise et validée par des implémentations parallèles en N-versions, permet à un développateur unique de produire cinq ports logiciels distincts en environ 120 heures, réactivant ainsi la méthodologie de programmation en N-versions des années 1980 qui était devenue trop coûteuse.

Auteurs originaux : Jason Hickey

Publié 2026-06-09

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jason Hickey

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous vouliez construire cinq versions différentes d'une application de dessin complexe et haut de gamme (comme un mini-Adobe Illustrator). Dans l'ancien temps, cela reviendrait à embaucher cinq architectes de génie différents, parlant chacun une langue différente, pour concevoir la même maison. Cela prendrait des années et coûterait une fortune.

Jason Hickey, un développeur solitaire, a fait quelque chose de différent. Il a construit cinq versions fonctionnelles de cette application (pour Rust, Swift, OCaml, Python et un navigateur web) en seulement sept semaines, en travaillant uniquement le soir. Il n'a pas embauché une équipe ; il a utilisé l'IA comme partenaire.

Voici comment il a procédé, expliqué simplement :

1. Le « Plan Directeur » (La Spécification Exécutable)

Habituellement, lorsque vous construisez un logiciel pour différentes plateformes, vous devez écrire les règles de l'application de zéro, cinq fois de suite. Si vous voulez modifier le fonctionnement d'un sélecteur de couleurs, vous devez mettre à jour cinq bases de code différentes.

Hickey a fait l'inverse. Il a écrit un seul « Plan Directeur » (un document de 23 000 lignes écrit dans un langage appelé YAML).

L'analogie : Considérez ce plan non pas comme un PDF statique, mais comme une recette vivante. Il ne dit pas seulement « faites un bouton rouge » ; il dit : « Voici exactement comment le bouton apparaît, comment il réagit quand on clique dessus, et ce qui se passe ensuite. »
La magie : Ce plan est « exécutable ». L'ordinateur lit cette recette unique et construit automatiquement l'interface utilisateur pour les cinq applications différentes. Si Hickey veut changer une règle, il la modifie à un seul endroit, et cela met instantanément à jour les cinq applications.

2. Le « Dragon à Cinq Têtes » (La Programmation N-Version)

Dans les années 1980, les ingénieurs ont tenté une méthode appelée « Programmation N-Version ». L'idée était : « Si nous construisons cinq versions différentes d'un système de manière indépendante, et qu'elles sont toutes d'accord, alors c'est correct. Si elles ne sont pas d'accord, nous savons qu'il y a un problème. »

Le problème : C'était trop coûteux. Construire cinq équipes différentes pour écrire cinq versions différentes du même code était un gaspillage d'argent.
Le tour de magie de l'IA : Hickey a relancé cette idée en utilisant l'IA. Comme l'IA peut faire le gros du travail de rédaction du code pour les différents langages, il a pu se permettre de construire cinq versions en étant une seule personne.
Le filet de sécurité : Ces cinq versions agissent comme un jury de cinq personnes. Si la version « Rust » de l'application fait passer une couleur au rouge, mais que la version « Python » la fait passer au bleu, le système signale immédiatement un problème. Elles effectuent un « test différentiel » entre elles. Si elles ne sont pas d'accord, cela signifie que le Plan Directeur était imprécis ou qu'une des versions a commis une erreur.

3. La « Trappe de Secours » (L'Échappatoire)

Le Plan Directeur couvre environ 90 % du travail. Mais parfois, une plateforme spécifique (comme un iPhone ou un navigateur web) nécessite une astuce particulière que le plan général ne peut pas décrire.

L'analogie : Imaginez que le plan soit un plan de maison standard. Mais la maison « Rust » a besoin d'un sous-sol renforcé spécial parce que le sol est rocheux. Le plan gère les murs et le toit pour tout le monde, mais l'équipe « Rust » doit construire son propre sous-sol spécial.
Hickey appelle cela la Trappe de Secours. Il s'agit de la petite quantité de code personnalisé nécessaire pour chaque plateforme spécifique, tandis que le reste est partagé.

4. Comment le processus a fonctionné (La Boucle)

Hickey n'a pas simplement tapé du code en espérant que cela fonctionne. Il a utilisé une boucle spécifique :

Conception : Il a écrit un plan en langage clair.
Révision par l'IA : Il a demandé à l'IA de trouver les failles dans le plan (« Qu'est-ce qui manque ? Qu'est-ce qui est confus ? »).
Mise à jour du Plan Directeur : Il a mis à jour le Plan Directeur en fonction des conseils de l'IA.
Construction et Test : L'IA a généré le code pour les cinq applications.
Vérification par l'« Œil Humain » : C'était la partie la plus lente. Hickey a examiné manuellement les cinq applications côte à côte. Si l'une d'elles paraissait étrange, il savait que le Plan Directeur devait être corrigé.

Le Résultat

Temps : Environ 120 heures de travail en soirée (soit environ 7 semaines).
Résultat : Cinq applications pleinement fonctionnelles partageant une logique centrale.
Coût : Au lieu de « plusieurs années-développeurs », cela a pris à une seule personne quelques mois.

Le Bémol (Limites)

L'article est honnête sur ce qu'il ne fait pas :

Ce n'est pas un produit fini : Les applications sont dépourvues de certaines fonctionnalités avancées présentes dans les outils professionnels (comme les maillages 3D complexes ou les fonctions d'impression professionnelles). C'est un « sous-ensemble substantiel », pas un clone parfait.
Cela dépend de l'IA : Si l'IA s'embrouille ou « hallucine » (invente du faux code), le système le détecte car les cinq versions seront en désaccord. Mais si l'IA est mauvaise sur une tâche spécifique, tout le processus ralentit.
Cela nécessite un humain : L'IA a fait la saisie, mais un humain a dû vérifier les résultats, corriger la logique et gérer la « mémoire » du projet pour que l'IA ne perde pas de vue ce qu'elle avait décidé la veille.

La Grande Leçon

Cet article soutient que l'IA a changé l'économie de l'ingénierie logicielle.
Auparavant, construire plusieurs versions d'un logiciel pour garantir la qualité était trop coûteux. Désormais, avec l'IA qui gère la partie répétitive du codage, un développateur seul peut construire un « jury » de cinq applications pour vérifier leur travail respectif. Cela transforme une méthode qui avait été abandonnée dans les années 1980 en raison du coût en un outil pratique pour une seule personne aujourd'hui.

Résumé technique : L'ingénierie couplée à l'IA comme renouveau de la programmation N-version

Énoncé du problème
Les applications matures d'illustration vectorielle (par exemple, Adobe Illustrator, Inkscape) représentent des décennies de développement par de grandes équipes pérennes. Historiquement, étendre de telles applications ou les porter sur de nouvelles plateformes était considéré comme hors de portée pour un développeur individuel en raison du volume massif de code, de la complexité des frameworks d'interface utilisateur (UI) et de la nécessité d'une rigueur absolue en matière de correction. Le présent article examine si l'ingénierie couplée à l'IA peut modifier cette réalité économique, permettant à un développateur seul de produire plusieurs implémentations de haute fidélité d'une application de bureau complexe en une fraction du temps traditionnellement requis.

Méthodologie
L'auteur, Jason Hickey, a employé une méthodologie centrée sur deux garanties spécifiques pour permettre l'« ingénierie couplée à l'IA » à grande échelle :

Une spécification précise et exécutable (Source unique de vérité) :
- Le cœur du projet est une spécification YAML de 23 000 lignes qui définit de manière déclarative les panneaux, les boîtes de dialogue, les outils, les menus, les modèles d'état et les comportements réactifs de l'application.
- Cette spécification est exécutable : un interprète partagé (environ 12 500 lignes) lit le YAML au démarrage et construit l'interface utilisateur directement, plutôt que de traiter le YAML comme une documentation à réencoder dans chaque langage.
- La méthodologie utilise un modèle de « trappe de secours » (escape hatch) : là où le YAML déclaratif ne peut exprimer les nuances spécifiques à une plateforme (par exemple, le rendu accéléré par matériel, la gestion spécifique des gestes), du code natif est écrit. Cependant, la logique conceptuelle reste dans le YAML, garantissant que les décisions de conception sont prises une seule fois et propagées à tous les ports.
Implémentations parallèles comme couche de test différentiel intégrée :
- Au lieu d'une implémentation unique, le développateur a construit cinq ports fonctionnels à travers des langages et des frameworks distincts : Rust (Dioxus), Swift (SwiftUI), OCaml, Python (PySide6) et une esquisse basée sur le navigateur avec Flask/HTML.
- Ces implémentations parallèles fonctionnent comme un contrôle continu de la correction. Parce qu'elles partagent la même spécification mais utilisent des rendus natifs et des idiomes de gestion d'état différents, les divergences de comportement ou de rendu visuel signalent immédiatement soit un bug dans une implémentation, soit une sous-spécification dans le YAML.
- Cette approche fait revivre la programmation N-version (Avizienis, 1985). Alors que la méthodologie originale des années 1980 a été abandonnée en raison du coût prohibitif de la création de $N$ implémentations indépendantes, l'auteur soutient que l'IA change fondamentalement l'économie. L'IA gère le travail mécanique par port, rendant $N$ implémentations réalisables pour un seul développeur, tandis que la diversité des plateformes fournit l'indépendance nécessaire pour détecter les erreurs que les tests automatisés manquent.

Principales contributions

Une étude de cas : Un développateur seul a produit cinq ports multiplateformes d'une application d'illustration vectorielle (27 outils, 14 panneaux, 22 boîtes de dialogue) en environ 120 heures de soirée (7 semaines calendaires).
Cadre méthodologique : Un flux de travail spécifique couplant une spécification exécutable à des implémentations parallèles en tant que couche de test différentiel.
Rapport de terrain pratique : Documentation détaillée de l'ingénierie couplée à l'IA en pratique, incluant :
- Ingénierie de prompt : Boucles itératives pour convertir les conceptions textuelles en YAML et revues périodiques du code source.
- Gestion d'état : Le rôle critique de la mémoire persistante basée sur des fichiers (57 entrées) pour maintenir le contexte entre les sessions.
- Modes de défaillance : Rapport honnête des limites de l'IA, telles que les « hallucinations confiantes » de symboles, la dérive du contexte long et la tendance à choisir une interprétation d'une exigence sous-spécifiée sans signaler l'ambiguïté.
Artefacts Open Source : Le projet complet, incluant la spécification de 23 000 lignes, les cinq ports, 4 600 tests automatisés et les protocoles de tests manuels, est disponible sur github.com/jyh/jas.

Résultats

Échelle et portée : Le projet a abouti à environ 336 000 lignes de code total (incluant l'interprète partagé et les cinq ports). La spécification YAML partagée a piloté la logique, tandis que le code natif par port variait de 0 ligne (OCaml, entièrement piloté par le YAML) à environ 95 000 lignes (Rust, nécessitant un rendu personnalisé important).
Correction via la divergence : La stratégie d'implémentation parallèle a permis d'identifier avec succès des lacunes de spécification qui auraient été « silencieusement erronées » dans un port unique. Exemples incluant :
- La gestion des canaux de couleur dégénérés (par exemple, la saturation HSB tombant à zéro).
- Le timing des comportements d'aimantation (« snap ») en mode Web Safe RGB.
- La persistance de l'état dans les contextes de boîte de dialogue (par exemple, la réversion du champ hexadécimal).
- La logique des « couleurs récentes » lors du glissement de curseur.
Effort : L'effort total est estimé à 120–160 heures de développement. L'auteur note qu'un port unique de portée comparable utilisant des outils conventionnels nécessiterait typiquement 1 à 2 années de développeur ; cinq ports nécessiteraient conventionnellement plusieurs années de développeur.

Signification et affirmations
L'article ne prétend pas que l'application résultante égale la complétude de fonctionnalités des outils commerciaux matures (elle manque de façonnage de texte avancé, d'effets de trame et de pleine fidélité SVG). Au lieu de cela, sa signification réside dans la démonstration d'un déplacement de la frontière de faisabilité pour les développeurs individuels.

L'auteur soutient qu'en combinant une spécification exécutable précise avec des implémentations parallèles générées par l'IA, un développeur seul peut atteindre une portée de travail qui nécessite conventionnellement plusieurs années de développement. Cela est présenté comme une renaissance de la programmation N-version, où la barrière économique de la création de multiples implémentations indépendantes est abaissée par l'IA. La méthodologie suggère que pour les domaines descriptibles de manière déclarative (comme l'UI et la logique applicative), la valeur de « test différentiel » de plusieurs ports peut être réalisée sans le coût traditionnel, à condition de maintenir une surveillance humaine rigoureuse et des protocoles de gestion de la mémoire.

L'article reste modeste, reconnaissant que les résultats sont un instantané des capacités actuelles de l'IA (Claude Opus 4.6/4.7 en 2026) et que la méthodologie repose fortement sur l'expertise métier du développeur et sa capacité à gérer les modes de défaillance de l'IA. L'affirmation n'est pas que l'IA remplace le besoin de supervision humaine, mais qu'elle change l'équation économique de la programmation N-version, faisant d'elle une stratégie viable pour les développeurs individuels afin d'assurer la correction et la portabilité.