Naissance d'une application — prototyper ou échafauder

Vous êtes ici : Comprendre — la gouvernance : ce qui se passe avant qu’une application existe. Comment on choisit entre prototyper d’abord et construire directement, et ce qui encadre un prototype. Lecture 6 min. Audience : devs, décideurs produit. Date : 2026-08-11 | Version : 1.0 — créée par la refonte de l’architecture d’information

Le principe central — l'incertitude porte-t-elle sur le QUOI ou sur le COMMENT ?

C’est la seule question à poser, et elle décide de tout le reste.

• L’incertitude porte sur le quoi — quels écrans, quelle métrique est utile, est-ce que ça sert vraiment ? → on prototype. Le prototype est un cahier des charges navigable : il montre ce qu’un document décrirait mal.
• L’incertitude porte seulement sur le comment — un traitement de fond, une interface interne, un module calqué sur un existant ? → on construit directement. Un prototype n’y apprendrait rien et ne ferait que retarder.

Avant, ce choix se faisait par habitude. C’est maintenant un critère écrit.

Les deux recettes

	Prototype d’abord	Construction directe
Quand	Le besoin n’est pas stabilisé	Le besoin est déterminé
Où ça vit	Hors de la plateforme	Dans la plateforme, dès le premier jour
Ce que ça produit	Un artefact d’exigences navigable	Une application soumise aux gardes du parc
Ce que ça coûte si on se trompe	Un prototype jeté — c’est le but	Des écrans de production à défaire

Pourquoi le prototype vit à l'extérieur

Une application de la plateforme naît avec beaucoup de choses : isolation par compagnie, gestion des accès, bilinguisme, câblage au catalogue de données, infrastructure déclarée. C’est ce qui la rend sûre — et c’est du travail qu’on jettera si le besoin n’était pas le bon.

Faire payer ce prix à une exploration, c’est décourager l’exploration. Le prototype s’en affranchit volontairement ; en contrepartie, il n’a pas le droit d’entrer en production tel quel.

Le chemin vers la production est unique

Un prototype ne devient jamais une application de production par durcissement sur place. Il n’a ni les gardes d’isolation, ni la gestion des accès du parc, ni le câblage écosystème : le « promouvoir » reviendrait à importer une dette qu’aucun contrôle ne rattrape après coup.

Le seul chemin est une intégration : l’application est reconstruite dans la plateforme, en se servant du prototype comme spécification. Puis le prototype est gelé et son hébergement retiré.

Jamais deux versions vivantes

Le gel du prototype après intégration n’est pas de l’hygiène : c’est la règle qui empêche une deuxième version de continuer à évoluer en parallèle. Deux versions vivantes du même produit, c’est deux vérités — et des utilisateurs qui travaillent sur la mauvaise sans le savoir.

La charte du prototype — dès le premier jour

Quatre clauses vérifiables, applicables à la création du prototype et non au moment de son intégration :

Clause	Ce qu’elle exige
Zéro donnée personnelle réelle	Noms fictifs, domaine d’exemple. Aucune donnée d’employé ou de client, même « juste pour la démo »
Date de péremption déclarée	Un prototype sans fin annoncée devient un système de production accidentel
Hébergement identifié	On sait où il tourne, donc on saura l’éteindre
Espace gouverné	Dès que le prototype touche une surface de données personnelles — même fictive — il vit dans un espace administré

Pourquoi la charte s'applique au jour 1, et pas à l'intégration

Parce que la donnée personnelle entre dans un prototype le jour où on le remplit, pas le jour où on décide de l’intégrer. Un hébergement non gouverné peut vivre des mois avant qu’une intégration soit seulement envisagée.

Une charte qui ne s’applique qu’à la sortie n’a jamais empêché la dérive qu’elle vise. Et le moment le plus risqué d’un projet est précisément celui où un prototype impressionne : c’est là qu’il glisse en production sans son ménage.

Les limites, assumées

La doctrine déclare son propre point faible : un prototype qui vit hors de la plateforme échappe par construction aux contrôles automatiques du parc. Aucune garde d’intégration continue ne peut lire un dépôt qui n’est pas là.

La charte repose donc sur une vérification humaine, bornée par la date de péremption. C’est le prix assumé de la vitesse de découverte — et il est écrit, plutôt que découvert plus tard.

Le cycle complet

Une application a un début et une fin. La même exigence vaut aux deux bouts : de même qu’un prototype déclare sa péremption, une application de la plateforme naît avec un contrat de décommission — la garantie qu’on pourra la retirer sans démêler ses données de celles des autres. C’est ce que rendent possible les frontières visibles décrites dans le parc applicatif.

Pour aller plus loin

• Parc applicatif — les modules existants et leurs frontières.
• Comment GS-Apps décide — le circuit qui a produit cette doctrine.
• Index des savoir-faire — les procédures détaillées de naissance et de retrait.
• Intégrer une application — le versant technique de l’intégration.