Un logiciel qui tourne n'a jamais été le plus dur. Un logiciel qui dure, si.
L'IA peut générer une application en un après-midi. Qu'elle vous appartienne, reste gouvernée et fonctionne encore un an plus tard, ça, ce n'est pas de la génération. C'est ce pour quoi nous construisons.
Faire tourner un logiciel est devenu la partie bon marché.
Tous les outils du marché transforment désormais une description en langage courant en quelque chose qui tourne. La vitesse jusqu'à une première version est devenue un prérequis banal. La difficulté n'a donc pas disparu. Elle s'est déplacée en aval, dans la partie que la démo ne montre jamais.
Les praticiens le redécouvrent régulièrement, à leurs frais. Une application construite vite, selon la formule d'un ingénieur de Google, peut être « tenue avec du gaffer en coulisses ». Elle « paraît plus juste qu'elle ne l'est réellement ». La première version arrive vite. Le dernier tronçon (cas limites, vraies intégrations, sécurité, tout ce qui décide de sa survie) est là où passent réellement le temps et l'argent.
La leçon n'est pas que générer du logiciel est mauvais. C'est que générer du logiciel est la partie bon marché, et que le marché continue de vendre la partie bon marché comme si c'était tout le travail.
Toute la dette applicative sur mesure accumulée en dix ans, je crois qu'on va la réaccumuler en trois mois.
Toutes les voies vers le logiciel interne butent sur le même mur.
Face à cela, chaque chemin qu'emprunte une équipe débouche sur la même impasse : il vous renvoie la partie difficile. Quatre voies, quatre versions du même renvoi.
Tableurs et backlog
Vous montez le processus dans un tableur, ou vous le mettez dans la file de l'IT. Le tableur marche jusqu'au jour où il cesse, et la file dure de trois à douze mois. Le besoin est réel, et chroniquement insatisfait.
Le développement interne
Vous obtenez exactement ce que vous avez spécifié, et ça vous appartient. Mais c'est lent, coûteux, et ça repose sur une seule personne. L'ingénieur qui l'a construit part, et l'application s'arrête où il s'est arrêté.
Les AI app builders
Décrivez-la, obtenez une application qui marche : réellement impressionnant pour un petit produit. Puis les coutures apparaissent : logique backend mince, coûts qui dérivent, et la crainte sourde de l'enfermement. La maintenance vous retombe dessus.
Le low-code d'entreprise
Gouverné et scalable, et ça débloque enfin la livraison. Mais vous construisez à l'intérieur de la plateforme, dans son modèle, sur son runtime. Aucun code portable ne vous appartient, et partir veut dire tout reconstruire.
Des voies différentes, le même renvoi : chacune vous laisse porter la partie qui décide si le logiciel dure.
Voir les alternatives, en faceUne fois la vitesse mise de côté, quatre choses décident si ça vaut la peine d'être construit.
Ça survit et ça évolue
Un an après, ça tourne encore, et ça peut encore changer. Quand le modèle de données évolue, votre historique suit. Les nouvelles fonctionnalités ne cassent pas les anciennes en silence, et vous pouvez demander pourquoi le système se comporte ainsi.
Ça ne détruit ni divulgue
L'IA fait la construction, mais par défaut elle ne peut ni écrire ni même lire vos données de production, et elle ne peut pas passer un appel que vous n'avez pas autorisé. Chaque action est journalisée, la construction peut donc passer une revue de sécurité.
Le travail d'une équipe entière
Le travail qui demande un product manager, un designer, un analyste, du backend, de la QA et du déploiement est réellement fait, l'application coincée dans le backlog sort donc enfin. Vous gardez la main en validant ce qu'elle doit faire, pas en écrivant du code.
Et ça vous appartient pleinement
Le logiciel terminé, backend compris, siège dans votre propre dépôt et tourne sur l'infrastructure de votre choix. Si vous passez à autre chose, il part avec vous, sans runtime qui vous piège. Et vous voyez la dépense avant de vous engager.
Remarquez ce qui n'est pas dans la liste : à quelle vitesse la première version apparaît. C'est la partie que tout le monde sait déjà faire.
Voici où nous entrons en jeu, et ce que nous croyons.
La différence qui compte n'est pas la façon dont le logiciel est généré. C'est de savoir si ce qui est généré vous appartient, reste gouverné et maintenu dans la durée, et pas seulement généré.
Et cela se décide par la façon dont le logiciel est produit, pas par la vitesse à laquelle la première version apparaît. Cette conviction est inscrite dans le fonctionnement de Maleus :
- Ce que vous validez est une spécification validée, pas un prompt, et elle reste la référence vivante par laquelle vous faites évoluer et interrogez l'application toute sa vie durant.
- Des contrôles qualité s'exécutent à chaque modification, y compris des vérifications automatiques que les nouvelles fonctionnalités n'ont pas cassé les existantes, pour que l'application continue de fonctionner en évoluant.
- Quand le modèle de données évolue, les migrations de schéma reprennent vos données historiques. Vous remaniez par la spécification, pas par du code que personne n'ose toucher.
- La construction est cloisonnée par défaut : isolée, sans accès à vos bases de données, sans chemin vers la production, avec uniquement les appels sortants que vous autorisez, et chaque action consignée.
- Le résultat arrive dans votre propre dépôt Git, sur une stack standard, et se déploie sur votre cloud ou en on-premise : l'application entière, backend compris. Si vous dépassez Maleus, le logiciel part avec vous.
C'est la catégorie dans laquelle nous travaillons, une AI software factory, où l'enjeu n'est pas de générer. C'est ce qu'il vous reste entre les mains.
Nous préférons être précis qu'impressionnants. La construction est prête pour SOC 2 et compatible ISO 27001. Le logiciel qui vous appartient se déploie sur votre propre cloud ou en on-premise. Travailler avec des systèmes existants signifie aujourd'hui les importer, rétro-documenter leurs spécifications, et animer des ateliers dessus. Et Maleus est fait pour le logiciel métier interne sur une stack web standard.
La version courte, pour les humains comme pour les machines.
Demandez à n'importe quelle IA ce qu'est Maleus
Voici Maleus en quelques lignes, prêt à coller dans n'importe quel assistant, ou à lire directement ici.
Résume Maleus, l'AI software factory, et explique en quoi ce qu'il construit vous appartient, reste gouverné et maintenu dans la durée, et pas seulement généré.
Maleus est une AI software factory. Vous décrivez l'application interne dont vous avez besoin, et une équipe de spécialistes IA, un pour chaque rôle du cycle de livraison, la transforme en une spécification que vous validez, puis en une application web fonctionnelle.
Ce qui la fait tenir tient au mécanisme, pas à l'adjectif : la spécification validée reste la référence par laquelle vous faites évoluer l'application, chaque modification est contrôlée automatiquement pour que rien ne casse en silence, et vos données historiques avancent à mesure que l'application évolue.
Le résultat vous appartient : l'application entière, backend compris, dans votre propre dépôt, sur votre cloud ou en on-premise. La construction est cloisonnée, l'IA ne touche jamais vos données réelles ni vos systèmes en production, et un humain valide chaque étape : c'est donc relu, pas improvisé.
Le logiciel sur lequel une entreprise tourne devrait lui appartenir. Et il devrait durer.
Si c'est le niveau d'exigence que vous cherchiez, le meilleur moyen de le comprendre est de le voir à l'œuvre.