Présentation du cycle de vie du développeur citoyen de Tenex, un processus en six étapes qui transforme ce que les employés non techniques construisent avec l'IA, d'un prototype personnel à une solution de production fiable pour toute l'entreprise.
Par Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani), Suchi Patel et Ashwin Kadaru (@AshwinKadaru
Un framework de Tenex.co.
Le résumé
Le cycle de vie du développeur citoyen (Citizen SDLC) est un processus en six étapes (idée, porte d'entrée, triage, provisionnement, construction, exploitation et évolution) qui prend un logiciel créé par des employés non techniques avec l'IA et le fait passer d'un prototype personnel à une production encadrée. Un principe traverse chaque étape : l'IA effectue le travail, le code déterministe définit les garde-fous, et les humains gèrent les exceptions. Ce cycle existe parce que l'IA a réduit le coût de l'écriture de code à presque zéro et a déplacé le goulot d'étranglement en aval, vers la vérification de la solidité de ce qui a été construit et la gestion d'une flotte croissante d'applications une fois qu'elles sont en production.
L'un de nos clients est une société d'investissement. Un membre de son équipe de gestion de portefeuille, une personne qui n'avait jamais écrit une ligne de code, a construit le tableau de bord que toute son équipe utilise désormais quotidiennement. Il suit le travail de création de valeur dans plusieurs dizaines de sociétés du portefeuille. Elle l'a construit en interrogeant Claude, en itérant pendant environ deux mois. Chaque ligne a été écrite par l'IA.
Et c'est réussi. Les vues sont correctes, le flux de travail correspond à la façon dont l'équipe fonctionne réellement, et l'adoption a été immédiate. Elle a esquissé le bon produit avant qu'aucun ingénieur ne soit impliqué.
Ce n'est pas de la chance. Pendant des décennies, la personne qui comprenait un problème métier n'était presque jamais celle qui pouvait construire le logiciel pour le résoudre. Combler cet écart était un effort herculéen : un chef de produit pour transformer son problème en cahier des charges, des ingénieurs pour traduire le cahier des charges en code, et une place dans la file d'attente derrière tout le reste du plan de développement. Des mois s'écoulaient entre l'idée et l'outil, et ce qui était finalement livré était l'interprétation par quelqu'un d'autre de ce qu'elle voulait dire.
Cet écart vient de s'effondrer. Le pouvoir de construire est passé aux personnes qui comprennent réellement le processus, savent ce que signifient les données et vivent dans le flux de travail tous les jours. Elle a construit la bonne chose du premier coup parce qu'elle était la source. Personne n'a été placé entre elle et le code pour la traduire, ou pour se tromper légèrement. C'est la promesse du développement citoyen, et elle a tenu cette promesse.
Puis nous avons regardé sous le capot.
L'application entière était un seul fichier HTML. 540 Ko. Environ 5 300 lignes. Le jeu de données principal vivait à l'intérieur sous la forme d'un blob de données de 80 Ko sur une seule ligne. Lorsque le fichier devait être mis à jour, l'IA y avait ajouté des fonctions de correction qui réécrivaient les valeurs à chaque chargement de l'application. Sauvegarder son travail signifiait que l'application réécrivait son propre HTML, se téléchargeait sur votre ordinateur portable, et vous la retéléchargeiez sur un disque partagé en tant que nouvelle version. Si deux personnes modifiaient en même temps, le dernier à sauvegarder gagnait, et les modifications de l'autre disparaissaient.
Un jour, une fonction de sauvegarde a cherché un marqueur dans le fichier, ne l'a pas trouvé, et a réécrit ce qu'elle avait de toute façon. L'application entière de 540 Ko a été tronquée à 7 octets. En une seule écriture silencieuse, le tableau de bord sur lequel l'équipe s'appuyait chaque jour a cessé d'exister, et rien dans la façon dont il avait été construit n'était conçu pour détecter cela, l'arrêter ou le restaurer.
La plupart des dirigeants entendent cette histoire et concluent que le développement citoyen est une responsabilité à éliminer. Nous pensons que c'est la mauvaise leçon, et les entreprises qui agissent en conséquence vont perdre. La bonne leçon : elle a fait son travail brillamment. Personne n'avait construit la route sur laquelle le logiciel devait être livré.
Le goulot d'étranglement s'est déplacé
Pendant des décennies, construire un logiciel était la partie coûteuse. C'était lent, rare et coûteux, et tout le cycle de vie du développement logiciel a grandi pour le protéger. Spécifications, tickets, sprints, revue de code : chaque cérémonie dans le cycle de vie de développement traditionnel existe parce que l'écriture du code était le goulot d'étranglement.
L'IA a effondré cette étape à presque zéro, et le goulot d'étranglement s'est déplacé. Quand n'importe qui peut construire une application fonctionnelle en un après-midi, le travail coûteux n'est plus la construction. C'est ce qui vient après : s'assurer que ce qui a été construit est solide et sécurisé, et maintenir une flotte croissante de ces applications une fois qu'elles sont en production.
GIF
Et la construction ne ralentit pas, créant deux problèmes à résoudre :
Premièrement, la qualité sous le capot. Un agent sollicité à partir d'une page blanche par un non-ingénieur converge vers un logiciel bricolé qui fonctionne aujourd'hui et est impossible à maintenir pour toujours. Le fichier de 540 Ko n'est pas une exception ; c'est le résultat par défaut de la construction sans rails.
Deuxièmement, la prolifération. Chaque équipe veut sa propre application, et aucun service informatique central ne peut construire et exploiter manuellement des dizaines d'entre elles. Sans garde-fous, chacune est construite sur la pile que le constructeur ou le modèle a choisie : une base de données différente, un schéma d'authentification différent, des secrets stockés là où ils atterrissent. Bloquez les demandes à la place et elles ne s'arrêtent pas, elles passent simplement sous le radar. Dans les deux cas, vous héritez non seulement d'une flotte d'applications, mais aussi du fouillis d'infrastructure en dessous, et rien de tout cela n'est quelque chose que l'informatique peut raisonnablement sécuriser, prendre en charge ou expliquer.
Donc la vraie question que chaque entreprise s'apprête à affronter : comment laisser les employés non techniques livrer de véritables logiciels internes sans hériter de cette flotte ?
Les trois réponses par défaut échouent toutes :
1) Verrouiller. Les demandes s'accumulent, la patience s'épuise, et les applications fantômes sont construites de toute façon. Maintenant, vous ne pouvez rien voir. Vous ne pouvez pas gouverner ce que vous ne pouvez pas voir.
2) Laisser faire. Dirigez les non-ingénieurs vers des outils d'IA sans structure et célébrez les démos. C'est ainsi que vous obtenez le fichier de 540 Ko. Et vous ne pouvez pas rattraper cela après coup par une revue. Au moment où un monolithe apparaît dans une revue de code, c'est déjà un monolithe. Il faut le prévenir dès le départ.
3) Tout revoir. Mettez une approbation humaine sur chaque changement. Votre équipe informatique est réduite, le volume de construction explose, et maintenant chaque déploiement attend le calendrier d'un relecteur. Les revues tuent soit l'adoption, soit deviennent une simple formalité. Les deux résultats contrecarrent l'objectif.
Donc la réponse n'est pas un autre document de politique, mais un cycle de vie : un véritable cycle de vie de développement logiciel, conçu pour des personnes qui ne se considéreront jamais comme des développeurs, avec des garde-fous intégrés dans la plateforme plutôt que rédigés dans une note. Une route qui amène une construction de la première idée en langage clair jusqu'à la production encadrée sans jamais demander au constructeur de devenir un ingénieur. La personne fournit l'intention ; la plateforme fournit la discipline.
Un principe traverse chaque étape : l'IA effectue le travail, le code déterministe définit les garde-fous, et les humains gèrent les exceptions. L'IA rédige, classe et écrit. Le code décide ce qui est autorisé. Les personnes ne sont sollicitées que là où un jugement est réellement nécessaire. Retenez cette division ; c'est ce qui permet à l'ensemble de passer à l'échelle.
Nous l'appelons le cycle de vie du développeur citoyen (Citizen SDLC). Six étapes, chacune encadrée.
Étape 1
L'idée
Une personne décrit l'application en langage clair, avec l'aide de l'IA : ce qu'elle fait, qui l'utilise, quelles données elle touche, qui en est le propriétaire. Cela prend quelques minutes et se lit comme une note. Cela sert également de brief pour tout ce qui suit en aval. C'est le premier mouvement du modèle opérationnel : l'IA effectue le travail de transformer un brouillon en un artefact structuré.
Voici à quoi cela ressemble en pratique. Quelqu'un dans la finance de fonds tape : « Je veux un outil de suivi des avis d'appel de fonds. Pour l'instant, c'est un tableur que je mets à jour à la main et que j'envoie par e-mail tous les vendredis. » L'IA pose les questions que poserait un analyste de l'intégration. Qui d'autre a besoin de le voir ? Douze personnes dans la finance de fonds et les relations investisseurs. Où vivent les données aujourd'hui ? Un tableur dans Box, et un accès en lecture seule suffit. Qui en est le propriétaire quand vous êtes absent ? Son manager. Le brouillon est devenu un brief : objectif, utilisateurs, source de données, niveau d'accès, propriétaire, même une première estimation de la forme de l'application. Un cahier des charges produit, en effet, écrit par quelqu'un qui n'a jamais entendu le terme « cahier des charges ».
GIF
Rien n'existe encore. Pas de code, pas d'accès, pas d'infrastructure. C'est délibéré : l'entreprise se forge une opinion sur l'application avant que l'application n'existe, plutôt que six mois après qu'elle soit devenue critique.
Étape 2
La porte d'entrée
Chaque demande passe par une porte d'entrée structurée unique, et le même mouvement qui la dépose la place directement dans le triage. Le brief est la demande, le ticket que l'informatique voit, l'enregistrement permanent et une entrée dans un catalogue que tout le monde peut consulter, le tout en même temps. Pas de demandes dans les couloirs, pas de faveurs, pas de pipeline clandestin. Vous ne pouvez pas gouverner ce que vous ne pouvez pas voir, et vous ne pouvez pas partager ce que vous ne pouvez pas trouver. La porte d'entrée rend les deux vrais dès le premier jour.
C'est l'étape qui tue le pipeline clandestin. Une construction qui ignore la porte d'entrée peut encore exister en tant que prototype sur un ordinateur portable, mais elle reste là. Tout ce qui transforme un prototype en un logiciel sur lequel une équipe peut compter se trouve en aval de cette étape : stockage réel, connexion à l'entreprise, pipeline de déploiement, un endroit pour réellement l'exécuter. Rien de tout cela n'atteint une construction qui n'est jamais passée par la porte. Vous pouvez contourner la porte d'entrée ; vous ne pouvez tout simplement pas dépasser le prototype si vous le faites.
Étape 3
Le triage
L'IA classe la demande selon deux axes. Forme : de quel type d'application s'agit-il ? Un audit inverse de ce que les employés construisent réellement se réduit presque toujours à une courte liste : générateurs d'artefacts, automatisations de flux de travail, applications CRUD et tableaux de bord interactifs. Nommer la forme vous indique l'architecture dont elle a besoin, et elle donne à l'étape suivante la route pavée à tamponner. Rayon d'impact : quels dégâts cette construction pourrait-elle causer si elle tournait mal ? Nous notons cela selon quatre dimensions :
- Portée et capacité : à quoi peut-elle toucher, et peut-elle écrire ou seulement lire ?
- Réversibilité et autonomie : y a-t-il un humain dans la boucle, et l'action peut-elle être annulée ?
- Exposition : qui voit le résultat, et jusqu'où voyage-t-il en dehors de l'entreprise ?
- Sensibilité des données : à quel point les données avec lesquelles elle interagit sont-elles confidentielles ?
Mais voici la règle qui rend cela fiable : l'IA conseille. Le code décide. Le modèle lit le brief et le classe ; ensuite, le code de politique que l'informatique a écrit vérifie chaque classification par rapport aux règles. Regardez-le fonctionner sur le suivi d'appels de fonds. Forme : tableau de bord interactif. Rayon d'impact : données de fonds internes, douze utilisateurs internes, lecture seule, humain dans la boucle, aucun chevauchement avec les applications existantes. Chaque dimension se situe à l'intérieur des seuils approuvés, donc c'est approuvé, et aucun humain n'a discuté pour cela.
Changez maintenant un fait. Supposons que le suivi nécessite également des données d'engagement des LP. Le brief peut être aussi convaincant qu'il le souhaite ; ce seul changement fait monter la dimension de sensibilité des données au-dessus du seuil fixé par l'informatique, et la demande va à une personne. Aucune décision discrétionnaire n'a eu lieu entre-temps. Une règle correspond ou ne correspond pas.
Trois issues possibles :
- Approuvé. Rayon d'impact à l'intérieur de tous les seuils, brief complet, confiance élevée. Chez notre client, environ 9 demandes sur 10 se résolvent ainsi, automatiquement.
- Réutilisation. Elle chevauche une application qui existe déjà, donc le demandeur est orienté vers le propriétaire de cette application au lieu de construire un doublon. Les doublons sont fusionnés, pas multipliés.
- Escalade. Une dimension franchit son seuil, ou la confiance est faible. Un humain de l'informatique et de la sécurité reçoit la demande complète avec son contexte.
GIF
La dixième demande, la valeur aberrante, atterrit toujours sur le bureau d'un humain avec le brief complet joint. Les neuf autres n'ont jamais eu besoin de cela.
Étape 4
Le provisionnement
Voici la manœuvre qui permet à l'informatique de dire oui à volume : le provisionnement n'est pas l'informatique qui perd le contrôle de ce qui est livré, mais le contrôle de l'informatique qui remonte en amont. Au lieu de revoir chaque application après coup, l'informatique crée la route pavée une fois, et chaque application naît sur cette route. Une personne approuve, et la plateforme tamponne l'application à partir de la route pour sa forme : un dépôt, une connexion à l'entreprise, une identité de déploiement, un environnement privé et sa propre base de données, le tout défini comme une infrastructure en tant que code que l'informatique possède et versionne. Provisionné en quelques minutes.
C'est le seul moment où des privilèges élevés sont exécutés, et un humain est devant. Chaque application naît isolée, encadrée et auditée : son propre environnement cloisonné, pas d'adresse publique, pas de secrets cloud stockés, une piste d'audit en ajout seulement depuis le jour zéro. Le travail de sécurité a eu lieu une fois, dans la route. Aucune application n'a à le répéter.
Parce que la route est créée par forme, l'approbation humaine est une posture par défaut, pas une taxe permanente. Les formes nouvelles et les constructions à rayon d'impact élevé conservent la porte humaine pour toujours. Mais une fois que la route d'une forme a fait ses preuves sur suffisamment de constructions, les demandes à faible rayon d'impact sur cette route peuvent être provisionnées automatiquement. C'est la même logique « réservez le jugement humain pour la queue » appliquée une étape plus tôt : au début, vous orientez plus de choses vers une personne, et à mesure que les modèles se confirment, la ligne se déplace vers l'automatisation.
Et la route transporte une autre chose aussi importante que l'infrastructure : le manuel de règles de l'IA. Le dépôt hérité donne à l'agent de codage un ensemble d'instructions à chaque session, encodant les anti-modèles appris des échecs réels. N'intégrez pas de blobs de données de plus de 1 Ko. N'ajoutez pas de fonctions qui réécrivent les données lorsque l'application se charge. C'est ainsi que la qualité sous le capot est résolue sans demander au constructeur de connaître la moindre bonne pratique : la route fait en sorte que l'agent les suive. Chacune de ces règles est une cicatrice avec une histoire derrière elle (vous en avez lu une).
Étape 5
La construction
Le constructeur interroge son agent de codage (Claude Code, Codex, etc.) à l'intérieur d'un espace de travail cloud contrôlé, jamais sur son propre ordinateur portable. Un agent de terminal sur un ordinateur portable hérite de tout ce qui s'y trouve : courrier, disques synchronisés, cookies de navigation, identifiants mis en cache. Dans l'espace de travail, l'agent voit le projet. Rien d'autre.
Tout ce qu'un ingénieur transporterait normalement est transporté par les rails à la place : chez notre client, 35 garde-fous répartis en quatre couches que le constructeur ne peut pas désactiver.
La couche de fusion comprend des vérifications de dérive spécialement conçues pour le code généré par l'IA : budgets de taille de fichier, pas de données en ligne surdimensionnées, conformité de la piste d'audit. Vert ou ça ne fusionne pas. Lorsqu'une vérification échoue, le constructeur demande à l'agent de la corriger et pousse à nouveau.
Les humains ne revoient pas les changements de routine. Les vérifications sont la revue. Les changements de routine avancent à la vitesse de l'intégration continue, pas à la vitesse du calendrier d'un relecteur. Ce qui atteint un humain, c'est la queue conséquente, détectée mécaniquement : modifications destructrices de schéma, nouvelles dépendances, modifications des propres contraintes de l'agent, tout ce qui touche à l'infrastructure. Celles-ci attendent une personne. Rien d'autre ne le fait. Et quand quelque chose de nouveau s'échappe quand même, la solution est une nouvelle vérification automatisée, pas plus de revue humaine. Le système devient plus strict en encodant les leçons, pas en ajoutant des réunions.
Souvenez-vous du tableau de bord du début. Deux de ces vérifications de dérive auraient dû se déclencher sur lui dès la première semaine. Le blob d'une seule ligne de 80 Ko aurait échoué à l'intégration continue dès son tout premier commit, des mois avant que l'un des modes de défaillance ne se durcisse.
Étape 6
Exploitation et évolution
Six mois plus tard, le suivi d'appels de fonds fonctionne toujours, et c'est là que le cycle de vie montre sa valeur. Quelqu'un des relations investisseurs remet en question la date limite de virement sur l'avis de mars. La piste d'audit répond en trente secondes : qui a modifié le champ, quand, et ce qu'il disait avant, enregistré dans la même transaction que l'édition elle-même. Personne ne reconstruit la vérité à partir d'une chaîne d'e-mails. Lorsque le constructeur change d'équipe, la propriété est transférée à un successeur nommé plutôt que de se dissoudre dans un haussement d'épaules. Et si elle quitte l'entreprise complètement, sa connexion meurt et chaque porte qu'elle ouvrait se ferme en même temps. Le suivi inclus. La demande de fonctionnalité du prochain trimestre emprunte les mêmes rails que le premier commit.
La gouvernance fonctionne sur des signaux, pas sur des audits annuels. Les métriques d'utilisation du suivi montrent que deux autres équipes s'appuient dessus, donc il est promu et investi. Le tableau de bord des devises que personne n'a ouvert depuis avril est archivé, pas laissé pourrir dans un menu. Personne ne le pleure. La propriété est attribuée dès le premier jour, donc rien ne survit à son constructeur sans propriétaire. La documentation se régénère à mesure que l'application évolue, donc elle ne devient jamais obsolète. Une application inutilisée est un échec, pas un trophée. L'objectif n'a jamais été le nombre d'applications : c'est un catalogue vivant auquel vos personnes font réellement confiance, plutôt qu'un cimetière de logiciels oubliés.
À mesure que le catalogue passe de dix applications à deux cents, une équipe centrale ne peut plus garder un œil sur tout, et la supervision doit être repoussée vers les équipes qui possèdent les applications. Quand et jusqu'où déléguer cela est un jugement, et il évolue à mesure que le portefeuille grandit. La gouvernance ici est une posture que vous continuez à ajuster, pas un contrôle que vous définissez une fois.
La règle qui maintient le tout ensemble
Il y a un déclencheur que nous enseignons à chaque client, car il répond à 90 % des questions du type « est-ce que cela nécessite le processus complet ? » : la règle du deuxième consommateur. Elle fonctionne parce que c'est le moment où le profil de risque change.
Quelqu'un construit une analyse pour lui-même, sur son propre ordinateur portable, avec un accès aux données limité ? Faible rayon d'impact, gouvernance légère. Les graphiques, notes et scripts qu'il exécute pour lui-même n'ont pas besoin d'un pipeline de déploiement. Mais le moment où une deuxième personne veut utiliser le résultat directement, au lieu de demander des mises à jour à l'auteur ? Le rayon d'impact bondit : plus de portée, des données qui voyagent plus loin, quelqu'un d'autre qui fait confiance à leur exactitude. C'est maintenant un logiciel, et il passe au cycle de vie complet, délibérément, en tant qu'événement explicite. Mêmes sources de données, même identité, nouvelle route.
Cette seule règle explique pourquoi le processus ne noie pas les gens. La plupart des constructions ne franchissent jamais la ligne. Celles qui le font sont exactement celles qui valent la peine d'être célébrées.
Ce dont nous sommes honnêtes
Aucune plateforme ne fait écrire du code parfait aux constructeurs débutants. Nous ne prétendons pas le faire. Les couches existent pour qu'une erreur soit un inconvénient à l'intérieur d'une petite frontière, pas un incident à l'échelle de l'entreprise. Chaque couche couvre exactement ce que la couche supérieure ne peut pas couvrir :
Et l'audit n'empêche rien, mais il rend chaque incident court, explicable et attribuable. C'est la différence entre un mauvais après-midi et un mauvais trimestre.
Le développement citoyen n'est pas destiné à remplacer l'ingénierie professionnelle. Les systèmes d'enregistrement dans les processus réglementés, tout ce qui est destiné aux clients ou aux investisseurs, les applications construites pour des utilisateurs externes, tout ce où les temps d'arrêt entraînent une pénalité financière : tout cela appartient toujours à l'ingénierie, et la porte d'entrée les y oriente dès le premier jour. Ce qu'il remplace, c'est le goulot d'étranglement. Il démocratise la longue traîne des outils internes qui n'ont jamais valu un projet d'ingénierie formel et les livre à une vitesse que la file d'attente du plan de développement n'a jamais pu offrir. Un framework sans limites n'est qu'un slogan ; celui-ci sait à quoi il ne sert pas.
Ce qui change réellement
Chez la société d'investissement, la première application passée par la plateforme est celle qui l'a motivée : le tableau de bord de l'histoire d'ouverture, reconstruit sur les rails. Mêmes écrans. Même constructeur. Maintenant avec un stockage réel, une connexion à l'entreprise et un historique de chaque modification. Il ne peut plus jamais se tronquer à 7 octets, car la classe de code qui a causé cela ne peut pas fusionner.
Environ 9 demandes sur 10 se résolvent déjà automatiquement, et cette part ne fait que croître. La plupart de ce que les constructeurs non techniques fabriquent est par nature à faible rayon d'impact. Outils internes, principalement en lecture, à petit public. À mesure que la route de chaque forme fait ses preuves, davantage de ces constructions deviennent sûres à provisionner et déployer sans aucun humain dans la boucle. L'attention humaine continue de se concentrer sur la queue conséquente et de s'amincir partout ailleurs.
Un « oui » prend des minutes aujourd'hui, et il tend vers l'instant, car « non » est intégré.
Chaque entreprise s'apprête à avoir des centaines de constructeurs. La plupart des entreprises décident encore si elles doivent en avoir peur ou s'en réjouir. Celles qui gagneront ne seront pas celles qui auront le plus de constructeurs. Elles seront celles qui auront les meilleures routes.
