Ingénierie27 octobre 2026· 9 min de lecture
L'ADLC de Maleus : notre cycle de développement avec des agents, du besoin à la production
Comment Maleus cadre, spécifie, code, teste, relit et exploite des applications avec des agents, pour des équipes qui ne lisent jamais de code.
Adrien MaretCTO
Sur cette page
- Les onze phases de l'ADLC Maleus
- 1. Le cadrage : creuser le besoin
- 2. Le découpage en versions : un arbitrage budgétaire
- 3. Les spécifications détaillées : du spec-driven development
- 4. Le plan d'implémentation : décider avant de coder
- 5. Le front-end d'abord, avec ses tests
- 6. Le back-end : la logique métier et ses tests
- 7. La réconciliation : brancher le front sur le back
- 8. Exécution des tests et corrections
- 9. Trois revues avant de valider la version
- 10. La recette : commenter en naviguant, à l'oral
- 11. Déploiement et exploitation
- Où l'humain garde la main
- En résumé
Découvrez comment Maleus peut accélérer vos équipes.
Si écrire du code avec des agents est devenu facile, produire une application fiable, testée, sécurisée et maintenue en production est une autre affaire, qui demande un cycle : un Agentic Development Lifecycle (ADLC). Voici celui de Maleus, le Maleus Development Lifecycle, de l'expression du besoin jusqu'à l'exploitation.
Le vibe engineering, c'est l'opposé du vibe coding. Le vibe coding promet à chacun de créer une application à coups de prompts, mais laisse à l'utilisateur tout ce qui fait un logiciel fiable : cadrer, spécifier, tester, relire, maintenir.
Sans compétence technique, impossible de savoir si ce qui a été généré tient la route. Le vibe engineering inverse la logique : l'utilisateur métier exprime son besoin et valide le résultat, et la rigueur d'ingénierie est prise en charge par les agents.
C'est ce cycle qui permet à Maleus de travailler en complète autonomie sur des tâches de plusieurs centaines d'heures : il livre dès le premier coup une application complète et fonctionnelle, sans bug, sans oubli ni hallucination, puis la fait évoluer sans casser ce qui existe.
Le cycle de Maleus est pensé pour des non-techniques (chef de projet, expert métier, dirigeant), à qui on ne demande jamais de lire du code.
Les onze phases de l'ADLC Maleus
L'ADLC Maleus se déroule en trois temps :
1. Le cadrage : creuser le besoin
Tout commence par un atelier de cadrage, dans lequel l'utilisateur exprime son besoin. L'objectif est de creuser ce besoin en profondeur : qui sont les utilisateurs (les personas), quels parcours ils suivent dans l'application (les flows utilisateurs), quelles règles métier s'appliquent. Il en sort un cahier des charges fonctionnel et technique, accompagné d'un prototype visuel.
L'utilisateur n'a besoin d'aucune compétence technique : il parle de son métier, de ses règles, de ses irritants. C'est l'atelier qui traduit ce besoin en cahier des charges fonctionnel et technique.
L'utilisateur valide le cahier des charges et le prototype : c'est la première validation humaine du cycle, celle qui fixe ce qu'on va construire.
2. Le découpage en versions : un arbitrage budgétaire
Une fois le cahier des charges validé, Maleus découpe toutes les fonctionnalités à développer en plusieurs versions, réunies dans une feuille de route.
Chaque version est chiffrée avant d'être lancée, si bien que le découpage devient un véritable arbitrage budgétaire, entre les mains de l'utilisateur.
Le coût du projet est connu avant de lancer quoi que ce soit : chaque version est estimée en tokens et en temps, et l'utilisateur choisit jusqu'où aller en connaissant le prix.
L'utilisateur valide la feuille de route et décide de lancer tout ou partie des versions : c'est la deuxième validation humaine du cycle, celle qui fixe le budget.
Cette phase est très importante : bien découper un projet donne du sens à l'implémentation, mais permet surtout de maîtriser le contexte des agents, qui travaillent version par version sur un périmètre restreint, ce qui évite les hallucinations et les bugs lors de l'implémentation.
3. Les spécifications détaillées : du spec-driven development
Pour chaque version, Maleus entre dans son cycle de développement. La première étape consiste à générer les spécifications fonctionnelles et techniques détaillées, dans un format de spécification propre à Maleus :
Ces spécifications détaillées cadrent ensuite tout le travail des agents. C'est du spec-driven development : les agents implémentent ce qui est spécifié, et les tests d'acceptance disent ce que « terminé » veut dire.
4. Le plan d'implémentation : décider avant de coder
Avant d'écrire la moindre ligne de code, Maleus rédige un plan d'implémentation complet, pour le front-end comme pour le back-end.
Ce plan décrit tout ce qu'il faut construire et, surtout, tous les tests qu'il va falloir écrire. Les tests ne sont pas ajoutés après coup : ils sont prévus dès le plan, à partir des spécifications et de leurs tests d'acceptance.
5. Le front-end d'abord, avec ses tests
À partir des spécifications et du prototype validé au cadrage, Maleus construit d'abord la partie visible de l'application : tous les écrans, toutes les interactions. Un agent écrit le code, puis un second agent écrit tous les tests prévus par le plan.
Ces tests rejouent les parcours des utilisateurs dans un vrai navigateur, comme le ferait un humain : cliquer sur un bouton, ouvrir une fenêtre, remplir un formulaire, trier un tableau. D'autres tests, plus légers, vérifient la logique de chaque écran, si bien que la quasi-totalité du code est couverte.
Ils sont écrits avant même que le back-end existe : les tests décrivent ce que l'application doit faire avant qu'elle sache le faire.
6. Le back-end : la logique métier et ses tests
Un agent écrit ensuite toute la partie serveur : les règles métier, les données et la façon dont l'application les enregistre.
Puis Maleus écrit les tests du back-end, qui vérifient chaque fonction du serveur jusqu'à ce qui est réellement enregistré, puis chaque règle métier, une par une.
Au total, quatre familles de tests couvrent l'application, du clic de l'utilisateur jusqu'aux données enregistrées, et toutes sont prévues dès le plan d'implémentation.
7. La réconciliation : brancher le front sur le back
Le front-end et le back-end ont été construits séparément, il faut maintenant les relier. Maleus génère automatiquement, à partir du back-end, le code qui permet au front-end de lui parler, puis vérifie que chaque action de l'interface correspond bien à une fonction existante côté serveur, si bien qu'aucun bouton ne peut appeler une fonction qui n'existe pas.
8. Exécution des tests et corrections
Un agent lance ensuite tous les tests : d'abord les tests end-to-end du front-end, puis tous les tests du back-end. Quand un test échoue, l'agent ne se contente pas de le faire passer : il revient aux spécifications, qui sont la source de vérité, pour savoir s'il doit corriger le code ou le test. Une fois tout au vert, la phase de développement de la version est terminée.
9. Trois revues avant de valider la version
Une phase de revue commence alors, en trois passes :
Maleus corrige les problèmes relevés, fait un commit et passe à la version suivante une fois celle-ci implémentée, le tout automatiquement.
10. La recette : commenter en naviguant, à l'oral
Une fois toutes les versions implémentées, l'utilisateur fait la recette. L'application tourne dans un environnement de développement, directement dans Maleus.
Il peut laisser des commentaires et des captures d'écran sur l'application, mais surtout parler à l'oral : il navigue dans l'application pendant qu'il parle, et ses commentaires sont rattachés à l'endroit où il se trouve. Maleus sait à quel moment de la navigation chaque commentaire a été fait, ce qui fluidifie la recette.
Tous ces commentaires sont envoyés à Maleus, qui crée une version pour les corriger, avec le même cycle que décrit plus haut.
11. Déploiement et exploitation
Une fois la recette satisfaisante, on déploie la dernière version sur deux environnements : staging, puis production. Ces environnements peuvent être hébergés directement dans Maleus, ou chez le client, dans un environnement externe qu'il gère. C'est la phase de run, elle aussi outillée :
Tous les rapports de bugs et les retours utilisateurs arrivent dans le projet Maleus. Là, ils peuvent être traités avec le cycle classique : atelier, versions, et tout le cycle de développement.
Où l'humain garde la main
Les interventions humaines sont pensées pour des non-techniques (parler de son besoin, valider une feuille de route, tester une application en la commentant), tandis que toute la partie technique est automatique.
Entre le découpage et la recette, ce sont les spécifications, le plan, les tests, la réconciliation et les trois revues qui encadrent le travail des agents.
En résumé
L'Agentic Development Lifecycle de Maleus, c'est un cadrage approfondi, un découpage en versions chiffrées, puis pour chaque version un cycle automatique de spécifications, de plan, de développement, de tests et de revues. La recette et l'exploitation bouclent le cycle, puisque chaque retour peut devenir une nouvelle version : c'est notre façon de faire du vibe engineering.
C'est aussi ce qui permet à Maleus d'enchaîner des centaines d'heures de travail autonome sans dériver, puis d'itérer sans rien casser, puisque chaque nouvelle version repasse par les mêmes spécifications, les mêmes tests et les mêmes revues.