Créer un logiciel métier pour la gestion de patrimoine avec Qwen 3.8

Résultat livré pour un cabinet de conseil

L'application générée cible directement les besoins d'une structure comptant entre 3 et 15 collaborateurs. Elle s'articule autour de 3 profils distincts pour refléter la réalité du terrain. Bernard, le dirigeant, accède à un tableau de bord de conformité global lui permettant de surveiller les préconisations bloquantes et de consulter le journal d'audit. Marc, le conseiller, dispose d'une vue filtrée sur son propre portefeuille de clients pour gérer ses dossiers. Julie, au back-office, supervise les contrats et les imports de données. Ces 3 profils illustrent les accès souhaités ; leur protection doit encore être vérifiée sur les données et les fonctions de cette première version.

Le cœur du système repose sur 5 moteurs de calcul spécifiques. L'adéquation, la valorisation, la fiscalité, la conformité LCB-FT et les rétrocessions sont gérées par des scripts Python dédiés. Ce choix technique s'impose naturellement. Les modèles de langage excellent dans la rédaction de code mais restent inadaptés pour effectuer des opérations mathématiques complexes et déterministes. En déléguant ces calculs à des algorithmes classiques, les formules deviennent explicites et testables ; leur exactitude et leur conformité demandent une validation métier.

L'interface finale se distingue par sa clarté. Contrairement aux productions habituelles de certains modèles concurrents qui ont tendance à surcharger les menus, le rendu visuel est aéré et professionnel. L'intégration d'une charte graphique précise dès le départ permet d'obtenir un environnement de travail dans lequel un professionnel de la gestion de patrimoine peut naviguer quotidiennement sans fatigue visuelle.

Risque de dépendance aux éditeurs historiques

Les cabinets de gestion de patrimoine paient chaque mois des licences onéreuses pour des logiciels rigides. Ces solutions standardisées imposent souvent des processus de travail qui ne correspondent pas exactement aux méthodes internes de chaque entreprise. Accepter cette situation revient à brider la croissance de la structure et à s'interdire toute optimisation sur mesure. La création d'un outil propriétaire élimine cette friction permanente.

S'en remettre exclusivement à un fournisseur externe crée un point de défaillance unique. Si l'éditeur modifie sa tarification ou tarde à intégrer de nouvelles normes réglementaires, le cabinet subit les conséquences sans aucun levier d'action. Maîtriser son propre code source redonne le contrôle total sur l'évolution de l'outil de production. Cette indépendance technologique devient un avantage concurrentiel majeur sur un marché très réglementé.

Préparation de l'environnement de développement

Le lancement du projet nécessite une documentation précise. Un cahier des charges détaillé est fourni à l'environnement OpenCode, accompagné d'une maquette visuelle au format HTML nommée allocation. Cette référence graphique contient déjà les codes couleurs, les états des boutons et la structure des composants. Le modèle n'a pas à deviner l'esthétique attendue, il se concentre uniquement sur la traduction technique de ces éléments en composants React.

La phase de planification permet de valider les choix architecturaux. Le modèle propose de lui-même une pile technologique cohérente comprenant Next.js pour l'interface, FastAPI pour le serveur et SQLite pour la base de données locale. Une fois ces paramètres confirmés, un plan d'action structuré en 25 étapes est généré. Ce séquençage inclut la création de données de démonstration et l'anticipation des risques potentiels liés aux calculs fiscaux.

Exécution et gestion des défaillances en direct

Le passage en mode construction révèle la puissance de l'agent autonome. La création de la structure des dossiers, appelée scaffold, monopolise la majorité du temps et de l'énergie du modèle. Cette fondation technique est indispensable pour accueillir ensuite les différents scripts et composants. Pendant cette phase, le modèle boucle sur ses propres erreurs pour affiner l'architecture avant de rédiger la logique métier.

La stabilité du processus est assurée par un mécanisme de sécurité indispensable. Lors de la génération, Qwen 3.8 Flash rencontre inévitablement des difficultés. Pour éviter que le système ne s'arrête brutalement, un modèle de repli prend le relais. GLM 5.2 intervient dans environ 40% des cas pour corriger les erreurs et relancer la machine. Dans cette démonstration, ce mécanisme permet au développement de reprendre après certaines erreurs ; les corrections produites restent à vérifier.

L'efficacité de cette configuration se mesure à sa consommation de ressources. À la fin de la génération, le contexte utilisé plafonne à 20% de sa capacité totale. Là où d'autres solutions atteignent rapidement leurs limites de mémoire, cette approche maintient une marge de manœuvre confortable pour continuer à itérer sur le code produit.

Verdict sur la première version générée

La livraison de la première version intervient après 1 h 51 min de travail autonome. Un premier obstacle apparaît immédiatement avec un système d'authentification défaillant pour les comptes de démonstration. Le signalement de cette erreur permet au modèle d'identifier le problème côté interface et d'appliquer un correctif instantané en simulant une requête directe. Les accès sont rétablis en quelques minutes.

L'inspection approfondie révèle les limites de cet exercice en un seul passage. L'interface souffre d'un défilement infini au lieu d'une pagination structurée. Du côté du back-office, les contrats sont visibles mais impossibles à ouvrir. Plus critique, certaines formules mathématiques dans le simulateur du conseiller ne renvoient pas les bons résultats. Ces défauts exigent une phase de débogage manuel pour rendre l'outil pleinement opérationnel.

Le bilan global reste extrêmement positif au regard de l'investissement initial. Bien que le résultat brut se situe légèrement en deçà de ce que produirait un modèle plus coûteux sur une instruction unique, la vitesse d'exécution et le coût dérisoire de l'opération valident la méthode. Obtenir une base de code aussi vaste et structurée en si peu de temps offre un point de départ solide pour tout développement sur mesure.