Prototypage évolutif

Objectif

Le prototypage évolutif sert à livrer une solution qui fonctionne pendant que ses exigences se découvrent encore. L'instrument d'élicitation est l'usage réel d'un incrément réel: on met en service une première version utilisable, on observe ce que les parties prenantes en font, et ce qu'elles en font décide de la version suivante. Le BABOK décrit cette mécanique en une phrase descriptive: les prototypes sont créés pour étendre des exigences initiales jusqu'à une solution fonctionnelle, à mesure que les exigences se précisent par l'usage qu'en font les parties prenantes.

Le livrable est la solution elle-même: l'incrément est le produit, et c'est pour cette raison qu'il doit être de qualité de production. Le BABOK ajoute une réserve qu'il vaut de garder telle quelle: le prototype peut être utilisé dans la solution finale. Le référentiel décrit une pratique et il n'énonce aucune obligation d'architecture, de qualité ou de sécurité. Ces obligations existent, elles sont lourdes et elles reposent ailleurs.

Puisque rien n'est jeté, il n'existe aucun moment ultérieur où les raccourcis seraient rattrapés, et le socle de qualité, architecture, sécurité, protection des données, tests, exploitation, se paie dès l'incrément zéro. La décision que la technique soutient est celle-ci: que construire ensuite? Elle la soutient par une preuve d'usage. C'est un gain réel, et il faut le nommer pour voir ce qu'il coûte: ce que les gens font d'un incrément mis en service est une exigence; ce qu'ils en disent en atelier est une opinion sur une exigence.

Usage

Quand l'utiliser

• Conception d'interface et système de design: l'artefact est un actif de production dès le premier trait.
• Le socle de production existe déjà: architecture, authentification, journalisation, tests et chaîne de livraison sont en place.
• Les exigences ne se laissent pas énoncer à l'avance: seul l'usage d'un incrément réellement utilisable les révèle.
• Domaine stable, solution petite: l'usage a peu de chances d'invalider l'architecture du premier incrément.
• Le commanditaire finance la mise en production dès le premier incrément: c'est le prix réel de la technique.
• La chaîne de livraison est déjà continue: sans elle, la boucle d'usage ne tourne pas.

Quand ne pas l'utiliser

• La question posée est « quoi construire? »: le prototypage jetable y répond pour une fraction du coût.
• Le socle de production n'est pas finançable au premier incrément: apprendre sur un prototype jetable, puis construire la solution proprement.
• Données personnelles ou sensibles, modèle de menace non posé: poser le modèle de menace et l'architecture d'abord, explorer l'interface par un prototype jetable.

Description

Deux axes indépendants

Le BABOK range les prototypes sur deux éléments distincts, et les confondre coûte cher. L'approche dit ce que l'artefact devient: on le jette, ou on le fait grandir jusqu'à la solution. La méthode dit de quoi il est fait et ce que quelqu'un en fait: un storyboard que l'on lit, un prototype papier que l'on manipule, une simulation que la machine exécute ou la modélisation des flux de travail, méthode empruntée dont la maison est la modélisation des processus. Tout prototype porte une réponse sur chacun des deux axes, et les deux réponses sont libres l'une de l'autre. Le prototypage évolutif est une réponse sur l'axe de l'approche: il fixe le sort de l'artefact et ne dit rien du médium. C'est le prototypage pris dans son ensemble qui règle l'aiguillage entre les deux axes, et la seule comparaison qui ait un sens est celle qui reste sur l'axe de l'approche: garder l'artefact ou le jeter.

L'artefact devient la solution

La mécanique tient en quatre temps qui se répètent. Un incrément est construit, il est mis en service auprès de vrais utilisateurs qui font un vrai travail, l'usage est observé et ce que l'on en apprend décide de l'incrément suivant, construit sur la même base de code. Le mot qui porte tout le poids est mis en service: une démonstration en salle, un bac à sable, un environnement de recette avec des données inventées ne ferment pas la boucle, parce qu'ils ne produisent pas d'usage. Ils produisent des commentaires, et l'on a alors le coût de l'approche évolutive sans son bénéfice.

De là vient la seule chose qu'il faut retenir de cette technique. Il n'y a pas d'événement d'abandon, donc il n'y a pas non plus d'événement de nettoyage. Aucune date du calendrier ne porte la mention « on jette le prototype et on écrit la vraie version ». Ce que l'incrément zéro a omis reste dans le produit, en production, pour la durée de vie du système. Le socle de qualité se paie donc en entier avant que la première question ait reçu sa réponse. C'est la facture réelle de la technique, et elle tombe au début.

Conduire un prototypage évolutif

1. Décider de l'approche, explicitement, avant la première ligne
   Le choix entre garder l'artefact et le jeter se prend une fois, et il ne se défait pas à bon compte: à partir du deuxième incrément, jeter signifie jeter du logiciel en service. Écrire la décision, écrire sa raison et écrire ce qui obligerait à la renverser.
2. Écrire d'avance le signal de renversement
   C'est le genre de signal que l'on reconnaît trop tard. Deux méritent d'être posés noir sur blanc: ce que l'usage d'un incrément apprend invalide l'architecture que l'incrément zéro a figée, ou l'incrément suivant ne peut pas être mis licitement entre les mains de vrais utilisateurs sous le régime cantonal de protection des données. L'un ou l'autre atteint, la suite ne consiste pas à corriger l'incrément. Elle consiste à geler la série, à traiter ce qui tourne comme un prototype jetable dont on tire la leçon et à reconstruire le socle sur l'architecture que l'usage a fini par désigner. Le coût de ce renversement croît à chaque incrément, ce qui est la raison d'en écrire le seuil avant le premier.
3. Payer le socle et l'appeler l'incrément zéro
   Authentification et autorisation, journalisation et journal d'audit, chiffrement, base légale du traitement des données, gestion des erreurs, jeu de tests automatisés, chaîne de livraison, supervision, sauvegarde et restauration. Si cette liste paraît hors de proportion avec la question que l'on cherche à trancher, ce sentiment est le bon, et c'est le signal qu'il faut un prototype jetable.
4. Définir le plus petit incrément qui puisse être réellement utilisé
   Par de vraies personnes faisant un vrai travail, avec de vraies données. Le critère est la capacité à produire de l'usage: un seul cas d'usage traité de bout en bout vaut mieux que cinq écrans à moitié branchés.
5. Mettre en production et faire utiliser
   L'instrument d'élicitation est l'usage réel, exercé par les personnes dont c'est le métier, dans les conditions où elles l'exercent.
6. Observer ce que les gens font de l'incrément
   Télémétrie, points d'abandon, tickets d'assistance, questions posées au guichet, contournements que les gens inventent. Un contournement est une exigence qui n'a pas été satisfaite, la donnée la plus riche que la technique produise.
7. Trancher l'incrément suivant sur cette base, avec les parties prenantes et écrire ce que l'usage a tranché
   Cette dernière clause est celle que les équipes sautent, et son absence est ce qui distingue un prototypage évolutif d'une simple suite de livraisons. Sans elle, la technique produit un système et aucune exigence: le code encode la décision, personne ne sait l'énoncer.
8. Tenir le socle à chaque incrément
   Aucun incrément ne passe sous le plancher. Le jour où l'un y passe, la dette contractée n'a plus d'échéance de remboursement, parce que le calendrier n'en prévoit aucune.
9. Reconnaître le moment où le mot « prototype » cesse de travailler
   Si chaque incrément est de qualité de production et que chaque incrément est livré, l'équipe fait de la livraison incrémentale, et il vaut mieux le dire et abandonner le mot.

Les livrables sont au nombre de trois, et le premier est celui que l'on voit. Il y a la solution, incrément par incrément, puisque l'artefact est le produit. Il y a le relevé, par incrément, de ce que l'usage a tranché, qui est la seule trace d'exigences que la technique laisse derrière elle. Il y a enfin les décisions d'architecture et de sécurité de l'incrément zéro, qui sont le plancher sur lequel tout le reste est posé et que personne ne rouvrira. HERMES 2022, la méthode que suit l'administration suisse, tient d'ailleurs le prototype et sa documentation pour deux résultats distincts de la tâche de prototypage, séparés des résultats du produit lui-même.

Le socle de qualité ne se rattrape pas

La sécurité est l'endroit où cette propriété cesse d'être une préférence d'ingénieur et devient une contrainte de nature. L'OWASP la formule dans les termes les plus nets, à propos des défauts de conception: « Une conception sécurisée peut encore comporter des défauts d'implémentation menant à des vulnérabilités exploitables. Une conception non sécurisée ne peut pas être corrigée par une implémentation parfaite, car par définition les contrôles de sécurité nécessaires n'ont jamais été créés pour se défendre contre des attaques précises. » Un défaut d'implémentation se corrige par un correctif. Une conception non sécurisée se corrige par une conception, c'est-à-dire par une réécriture, c'est-à-dire par l'événement d'abandon que cette approche a supprimé.

La CISA et ses partenaires internationaux disent la même chose du côté du fabricant: la sécurité s'intègre au produit dès sa conception et son développement, et c'est au fournisseur, non au client, d'en assumer le résultat. Or un prototype omet la sécurité par définition, et cette omission est une part de ce qui le rend rapide. Garder le prototype, c'est garder l'omission. Bâtir la sécurité par-dessus un artefact qui a été conçu sans elle est un échec programmé, au sens propre: le calendrier ne comporte aucune case où ce rattrapage pourrait avoir lieu.

En Suisse, cette exigence est en outre juridique. La protection des données dès la conception, principe posé à l'art. 7 de la loi fédérale sur la protection des données et repris par les lois cantonales sur la protection des données qui régissent les collectivités publiques cantonales et communales, impose des mesures techniques et organisationnelles dès la conception du traitement, ainsi que des réglages par défaut limitant le traitement au minimum. Un incrément zéro qui traite des données personnelles et qui remet la protection des données à plus tard est en défaut avant d'être en ligne.

La spirale de Boehm

La théorie correcte du prototype comme instrument a été écrite en 1988 par Barry Boehm, et elle est l'exact opposé de l'approche évolutive. Le modèle en spirale est piloté par le risque: chaque cycle identifie les objectifs et les options, identifie et résout les risques, le prototype étant l'instrument de choix pour cela, et ne s'engage sur le niveau d'élaboration suivant qu'une fois le risque racheté. Le prototype y sert à acheter une réduction d'incertitude avant l'engagement.

Le prototypage évolutif s'engage d'abord. L'incrément zéro est le produit, et l'architecture qu'il fixe est décidée au moment où l'équipe en sait le moins qu'elle en saura jamais. Ce sont deux attitudes opposées à l'égard du même instrument, et c'est en nommant la spirale qu'on les voit.

Ce que la spirale est devenue en pratique se dit exactement. Douze ans après l'article fondateur, Boehm a dû publier au Software Engineering Institute un rapport énonçant six invariants de tout développement en spirale, dans le but explicite d'écarter les hazardous spiral look-alikes, les faux airs de spirale qui en avaient pris le nom. Les modèles qu'il exclut sont exactement ce que les équipes faisaient sous cette étiquette: une suite d'incréments en cascade là où les hypothèses de la cascade ne tiennent pas, des cycles qui écartent des parties prenantes essentielles, des processus incrémentaux sans aucune planification architecturale, des démarches fixées sur le développement du code initial. Le rapport documente l'écart: sous le nom de spirale, les équipes faisaient autre chose, et il a fallu écrire les invariants pour distinguer l'usage authentique des faux airs. Qu'un tel rapport ait été nécessaire douze ans après l'article est la mesure de cet écart. Et le plus courant de ces faux airs, une suite d'incréments en cascade sans analyse de risque, est la forme que prend un prototypage évolutif mal conduit.

Économies et coûts de l'approche

Un prototype sert à apprendre. La question qu'il tranche est « quoi construire? », et c'est la question chère. Brooks l'a établi dans No Silver Bullet, et la phrase n'a pas vieilli: « La partie la plus difficile de la construction d'un système logiciel est de décider précisément quoi construire. » Aucune autre partie du travail conceptuel n'est aussi difficile, aucune ne mutile autant le système résultant si elle est mal faite et aucune n'est plus difficile à rectifier ensuite. Le reste, écrire le code, est ce que Brooks range du côté de l'accidentel.

Le coût que le prototypage évolutif prétend éviter est celui de réécrire du code. C'est le moins cher des deux, et il se paie après que l'apprentissage a eu lieu. Le coût qu'il fait payer, le socle de production, est le plus lourd, et il est encaissé avant. L'approche économise donc le mauvais coût, et elle le fait au moment le plus défavorable. En logiciel, ce n'est pas le choix par défaut, et il ne devrait pas l'être.

Brooks est allé plus loin, et sa conclusion est régulièrement enrôlée dans le mauvais camp. Dans l'édition anniversaire du Mythical Man-Month, il retire son conseil de 1975 (construire un premier système en sachant qu'on le jettera): « Je perçois maintenant que c'est faux, non parce que c'est trop radical, mais parce que c'est trop simpliste. » Ce qu'il embrasse à la place est la croissance incrémentale. Mais ce qu'il fait croître est le produit: son système part d'un squelette du système réel, qui tourne et n'appelle encore que des sous-programmes vides, puis que l'on étoffe morceau par morceau. Chaque étape est le produit. Il n'a jamais écrit qu'il fallait garder une maquette et l'étendre, et il ne tranche pas le débat entre les deux approches: il établit que le choix est réel et qu'il porte à conséquence.

La discipline qui décrit ce que Brooks recommande porte d'ailleurs un autre nom. Beck l'appelle la conception incrémentale: la conception se fait à la lumière de l'expérience, elle est différée jusqu'au dernier moment responsable et chaque incrément est de qualité de production et livré. C'est la source primaire de la pratique que l'on décrit parfois comme le cœur du développement agile, et elle ne s'appelle pas prototypage.

La conclusion tient en un énoncé: la discipline qui fait fonctionner le prototypage évolutif est celle qui le fait cesser d'être un prototype. Construire l'incrément zéro aux normes de production, tenir le socle à chaque incrément, écrire ce que l'usage a tranché: à ce moment-là, l'équipe fait de la livraison incrémentale, et le mot prototype ne fait plus aucun travail dans la phrase. Le manquer, c'est faire grandir une démonstration en système de production. L'approche n'a pas de milieu honnête. On retrouve cette distinction dans la structure d'HERMES 2022: le prototype réalisé et sa documentation y sont des résultats, le produit développé en est un autre et la méthode laisse le produit se construire de manière classique ou agile, sans qu'il ait besoin d'être appelé prototype pour être livré par étapes.

L'exception: la conception

Il existe un domaine où l'approche paie honnêtement, et il vaut d'être délimité. Dans un outil de conception d'interface comme Figma et ses semblables, l'artefact est un actif de production dès le premier trait. Le système de design est un ensemble de standards maintenus comme du code vivant et consommés par le produit livré, ainsi que le décrit le Nielsen Norman Group. Les jetons de design sont des variables que l'outil de conception et la base de code lisent tous les deux. Le CSS passe tel quel et le HTML dans une certaine mesure.

La raison en est structurelle, et c'est elle qui rend l'exception précise: sous un artefact de conception, il n'y a ni exécution, ni données persistées, ni surface d'attaque. Il n'existe donc aucun socle de qualité à rattraper. Rien dans un composant Figma ne peut être exploité, corrompre un enregistrement ou révéler l'adresse d'un habitant. L'exception s'arrête exactement là où l'artefact acquiert un moteur d'exécution et une base de données: la maquette d'écran survit dans le produit, le comportement qu'elle promet reste entièrement à construire et c'est ce comportement qui porte le socle.

Ce qui fait échouer un prototypage évolutif

La démonstration qui devient le système

Le BABOK nomme le mécanisme: quand le prototype est très élaboré et détaillé, les parties prenantes développent des attentes irréalistes pour la solution finale, y compris sur les dates d'achèvement, la performance et la fiabilité. Un incrément qui a l'air fini est traité comme fini, par le commanditaire et par l'équipe.

Une dette technique sans échéance de remboursement

La métaphore de Cunningham est précise, et elle est régulièrement citée à l'envers: livrer du code écrit au premier jet, c'est s'endetter, et une petite dette accélère le développement tant qu'elle est remboursée promptement par une réécriture. La dette qu'il décrivait est une compréhension immature du domaine, livrée dans du code, c'est-à-dire exactement ce qu'est un incrément précoce. Une approche dont la prémisse est que le code n'est jamais réécrit a retiré le remboursement du prêt.

La migration des données réelles, à chaque incrément

L'artefact est en service, donc il n'existe aucun moment où l'on vide la base et où l'on recommence. Toute évolution du schéma à partir de v1 est une migration exécutée sur les enregistrements de vraies personnes, avec sa reprise, sa réversibilité et sa trace, sous le régime de protection des données. Ce travail n'entre dans aucune estimation de prototype, et il grossit à chaque incrément.

L'architecture figée par l'incrément zéro

Le premier incrément est écrit sous la plus faible connaissance que l'équipe aura jamais du problème, et il devient le socle de tout le reste. C'est le miroir du piège précédent, et c'est ce qui rend l'approche viable sur un domaine stable et petit et punitive sur un domaine exploratoire.

La critique s'éteint

Le BABOK observe qu'avec une maquette les utilisateurs se sentent plus libres d'être critiques parce qu'elle n'est ni finie ni prête à être livrée. Un incrément en production est prêt à être livré, il l'est même déjà: les parties prenantes le critiquent alors comme un produit, avec prudence.

Le « comment » chasse le « quoi »

Première limite du prototypage selon le BABOK, et cette approche y est la plus exposée: l'artefact est du vrai code, donc la salle parle d'implémentation quand elle devrait parler de besoin.

Les exigences ne sont écrites nulle part

L'usage a tranché, personne n'a noté ce qu'il a tranché. Trois ans plus tard, une règle est dans le code et sa raison n'est nulle part.

L'outil spécialisé devient le plafond

Les plateformes à faible code rendent l'incrément zéro rapide et le socle invisible: authentification, hébergement des données, journal d'audit, coût de sortie. La vitesse est réelle, et elle se paie sur le socle.

Considérations IA

Une observation commande les autres, et elle est propre à cette technique: l'IA rend son mode d'échec plus probable. Il n'a jamais été aussi peu coûteux de produire quelque chose qui ressemble à une solution qui fonctionne: un incrément plausible, avec des écrans crédibles et un parcours qui se déroule, sans modèle de menace, sans modèle de données tenable, sans gestion des erreurs et sans exploitabilité. La distance entre une démonstration et un système de production n'a pas diminué; la distance entre l'air d'une démonstration et l'air d'un système de production s'est effondrée. La décision « cet incrément part-il en production? » reste humaine et engage une responsabilité.

Là où l'outillage rend un service considérable, il le rend sur le socle. Générer un incrément zéro complet, squelette d'application avec authentification, autorisation, journalisation, gestion des erreurs, jeu de tests et chaîne d'intégration, coûte aujourd'hui une fraction de ce que cela coûtait: la facture que cette technique refuse de payer a baissé, et c'est la seule chose qui puisse changer son économie. Revoir chaque incrément à l'aune des catégories de défauts de conception de l'OWASP, ébaucher un modèle de menace avant la mise en service, agréger les tickets d'assistance, les points d'abandon et la télémétrie d'un incrément livré en exigences candidates pour le suivant, rédiger le relevé de ce que l'usage a tranché, écrire les scripts de migration que chaque incrément exige parce qu'il tourne sur des données réelles: tout cela se délègue utilement.

Deux limites. La première est que l'IA rend l'argument du commanditaire plus fort: si écrire du code coûte encore moins cher qu'avant, alors conserver le code d'un prototype pour éviter de le réécrire achète encore moins qu'avant, tandis que la partie chère, décider quoi construire, reste exactement là où elle était. La seconde est que les incréments tournent sur des données réelles, celles de vraies personnes, dès l'incrément zéro. Aucun extrait du registre des habitants ne part dans un modèle exploité par un tiers, et le socle de protection des données lie l'outillage exactement comme il lie le produit.

Exemples

Une commune ouvre un guichet virtuel pour son contrôle des habitants. L'incrément zéro est le service en production: il est ouvert aux habitants d'une commune pilote, il délivre de vraies attestations de domicile à partir du vrai registre, et il le fait dès le premier jour.

L'incrément zéro a coûté plus que les trois suivants réunis. L'authentification et le journal d'audit écrits pour lui sont ceux qui tournent encore en production plusieurs années plus tard: ils ont survécu parce qu'ils ont été écrits aux normes de production le premier jour, sur un artefact que personne n'a jamais prévu de jeter.

La commune devait payer ce socle de toute manière. Le traitement porte sur des données personnelles, et la protection des données dès la conception s'impose au dossier avant la première ligne de code. La facture de v0 était donc due, et c'est ce qui rend l'approche défendable dans ce cas.

Le système encode la décision sur la représentation d'un tiers. Il ne l'énonce pas, et personne ne la retrouvera en lisant le code. Le relevé de ce que l'usage a tranché est le seul endroit où cette décision existe comme exigence: sans lui, la technique aurait livré un guichet et rien d'autre.

Visualisations

Ce qu'il faut voir dans la chaîne des incréments est un manque: il n'y a nulle part de poubelle, nulle part d'étape de nettoyage, aucune date à laquelle on repasserait derrière. Cette absence est la technique elle-même. Le relevé des incréments porte l'autre moitié de la même donnée: ce que l'usage a tranché à chaque étape et ce que le socle a coûté une fois pour toutes.

La même chaîne, posée à côté d'un projet réel, sert d'instrument d'audit, et trois contrôles s'y lisent. La bande du socle commence-t-elle bien à l'incrément zéro, ou commence-t-elle quelque part au milieu de la chaîne? Chaque incrément passe-t-il réellement par un usage ou seulement par une démonstration? Et existe-t-il, quelque part dans le plan, une date où l'on repasse derrière? Si la réponse à la dernière question est « on nettoiera plus tard », la réponse est une intention, et la technique ne prévoit aucun moment pour l'exécuter.

Coût

Outils

L'exception dispose de son propre outillage, et c'est le seul cas où le mot prototype et le mot production désignent la même chose sans réserve. Figma et ses semblables, avec leur bibliothèque de composants, les jetons de design et un catalogue de composants vivants comme Storybook, produisent un artefact que le produit livré consomme directement. Le système de design se maintient comme du code, et il se versionne comme du code.

Pour le logiciel, le BABOK relève que l'approche requiert habituellement un outil ou un langage de prototypage spécialisé, ce qui vise aujourd'hui les plateformes à faible code et à développement rapide (OutSystems, Mendix, Power Apps, Retool). Elles tiennent leur promesse: l'incrément zéro sort vite. Elles rendent aussi le socle invisible, et c'est le piège du chapitre entier: l'authentification, la localisation des données, le journal d'audit et le coût de sortie de la plateforme sont des décisions d'architecture, prises par défaut par l'outil, souvent sans que personne ne les ait vues passer. Le choix d'une telle plateforme se traite comme un choix d'architecture.

L'outillage qui porte réellement la technique est la chaîne de livraison: intégration et livraison continues, jeu de tests automatisés, drapeaux de fonctionnalité, environnements, supervision et retour arrière. C'est aussi le diagnostic le plus rapide qui soit: quand l'outillage nécessaire à une technique de prototypage est une chaîne de livraison complète, ce que l'équipe fait est une livraison, et l'outillage le dit avant qu'elle ne s'en aperçoive.

Reste l'observation de l'usage, sans laquelle l'étape qui définit les exigences n'a pas de matière: télémétrie applicative, journalisation des parcours, points d'abandon, tickets d'assistance, retours du guichet. Dans le secteur public suisse, tout cela s'exerce sous le régime cantonal de protection des données, avec un hébergement et une authentification conformes dès l'incrément zéro, ce qui est une contrainte d'architecture avant d'être une contrainte d'outil.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: l'approche évolutive ou fonctionnelle, les exigences précisées par l'usage des parties prenantes, l'outil spécialisé et les limites (attentes irréalistes, enlisement dans le « comment »).
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, ch. 19, Addison-Wesley, 1995: la rétractation du conseil de 1975 et la croissance incrémentale du produit.
• Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer 20(4), 1987: décider précisément quoi construire est la partie la plus difficile et la distinction entre difficulté essentielle et difficulté accidentelle.
• Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5), 1988, pp. 61-72: le prototype comme instrument de réduction du risque, résolu avant l'engagement.
• Barry Boehm (Wilfred J. Hansen, éd.), Spiral Development: Experience, Principles, and Refinements, Special Report CMU/SEI-2000-SR-008, Software Engineering Institute, 2000: les six invariants et les hazardous spiral look-alikes qu'ils excluent.
• Kent Beck avec Cynthia Andres, Extreme Programming Explained: Embrace Change, 2^e éd., Addison-Wesley, 2004: la conception incrémentale, la conception faite à la lumière de l'expérience et l'incrément livré en qualité de production.
• OWASP, Top 10:2021, A04 Insecure Design: une conception non sécurisée ne peut pas être corrigée par une implémentation parfaite.
• CISA et partenaires internationaux, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software: la sécurité intégrée dès la conception et le développement et la responsabilité du fournisseur.
• Ward Cunningham, The WyCash Portfolio Management System, OOPSLA '92: la métaphore de la dette technique, dans les termes de son auteur et le remboursement par la réécriture.
• Confédération suisse, Loi fédérale sur la protection des données (LPD), RS 235.1, art. 7: la protection des données dès la conception et par défaut, principe repris par les lois cantonales sur la protection des données.
• HERMES 2022, tâche Effectuer le prototypage: le prototype réalisé et la documentation du prototype comme résultats distincts, séparés des résultats du produit.
• Nielsen Norman Group, Design Systems 101: le système de design comme ensemble de standards maintenus et consommés par le produit livré.