Développer des applications métier avec l’IA : le retour d’expérience de Charles Bonnissent

Charles Bonnissent nous partage son retour d’expérience sur la transformation profonde du développement d’applications métier avec l’appui de l’IA et nous invite à retenir 3 points essentiels : 

• Le développeur déplace désormais son effort vers la conception et la validation, car la diminution de la connaissance détaillée du code produit rend les contrôles encore plus importants.
• Les gains de vitesse de développement sont surtout réinvestis pour l’instant dans la qualité justement, et ne se traduisent pas systématiquement par une livraison plus rapide de l’application.
• Même si la transformation est profonde, elle reste progressive. Le recours à l’IA pour la génération de code est déjà bien installé, mais l’extension à la conception fonctionnelle et à la co-construction nécessite encore de s’adapter efficacement… et c’est tout l’intérêt d’une plateforme comme AP4.

L’accélération du développement d’applications métier avec l’IA est déjà une réalité, mais cette production accélérée de code et d’applications pose évidemment des questions de sécurité, de maintenabilité et d’évolutivité. Comment garder la maîtrise de ce qui est créé ? Une question centrale abordée lors du webinar du 29 septembre consacré au développement avec l’IA et Anakeen Platform 4 (AP4). Charles Bonnissent, responsable R&D d’Anakeen, revient sur les changements dans son équipe, les méthodes mises en place et les limites rencontrées.

Charles, avec l’accélération de l’IA, sur quoi se concentre le travail du développeur désormais ?

On a intégré Claude Code progressivement, en commençant par les personnes les plus expertes, qui se sont approprié l’outil, et cela ensuite été étendu à toute l’équipe. On a alors vite vu que notre travail changeait profondément.

La part d’écriture manuelle de code a très vite diminué, et de manière très significative. On passe davantage de temps sur l’analyse fonctionnelle et la conception, puis sur les moyens donnés à l’agent IA pour vérifier ce qu’il a conçu. Car on a compris que plus il peut valider son travail, plus on peut lui confier des tâches longues.

Mais on perd aussi une partie de la compréhension fine du code sur les éléments qu’on ne réalise plus directement. Il faut donc être plus rigoureux sur la validation du résultat et sur son adéquation à la demande du client.

Quel cadre la plateforme AP4 apporte-t-elle au développement assisté par IA ?

Dans AP4, l’IA produit directement du paramétrage dans le langage de la plateforme. Elle s’appuie pour cela sur les mécanismes intégrés, et notamment en matière de sécurité dès la conception.

Pour que l’IA sache utiliser ce cadre, il a fallu lui donner accès à la connaissance du framework. Un de mes premiers projets d’envergure a donc été de reprendre toute la documentation technique : je l’ai vérifiée, puis reformatée et réécrite pour la rendre accessible aux agents IA. 

Le gros intérêt c’est que l’IA n’a pas à réinventer tous les fondamentaux d’une application. Grâce aux modèles d’applications déjà réalisés avec AP4, l’agent peut s’appuyer sur les mécanismes de la plateforme pour organiser les données, les étapes des processus et les droits associés des utilisateurs. 

On guide ainsi la réflexion de l’agent IA qui part de ce qu’on sait déjà réaliser avec AP4, et a donc moins d’incertitude sur la manière de répondre au besoin. Cela aide à limiter les explorations inutiles et la consommation de tokens. On peut alors concentrer le travail sur les usages métier et sur ce que l’application doit réellement permettre de faire.

Comment vérifiez-vous que l’agent IA conçoit bien ce qui est attendu ?

Développer avec un agent IA commence toujours par lui exposer la demande, on réunit le contexte, on pose les spécifications, puis on creuse avec lui la manière de réaliser les choses. Il propose un plan, et on le retravaille jusqu’à obtenir précisément ce qu’on souhaite faire. Une fois le plan validé, on lance le développement.

Ce qui nous a beaucoup aidé, c’est de travailler en mode TDD (Test-driven development), le développement piloté par les tests. On écrit d’abord des tests qui échouent avant d’écrire le code qui permet de les faire réussir. C’est une méthode qui existait déjà, mais qui était beaucoup plus lourde à utiliser lorsqu’on développait le code nous-mêmes. 

On commence aussi à intégrer des ADR (Architecture Decision Record), des documents qui gardent la trace de nos choix d’architecture. On les utilise pour orienter l’agent, mieux suivre les réalisations et éviter qu’il recrée des choses qui existent déjà.

Pour la recette, nous travaillons également sur des plans destinés aux agents et aux humains. Un agent vérifie ce qui a été produit, mais ce sont les humains qui valident au final que les fonctionnalités correspondent bien à l’attendu de départ.

Quels bénéfices observez-vous aujourd’hui sur les projets ?

On a gagné en vélocité, c’est sûr. Mais pour l’instant, cela ne se traduit pas forcément par des délais plus courts sur la livraison des applications métier. On a surtout utilisé ces gains pour augmenter la qualité de ce qui est produit, avec davantage de tests et de documentation. Pour la maintenance à long terme, cela permet de gagner en fiabilité et de moins dépendre des connaissances des personnes qui ont conçu le logiciel.

L’IA nous aide aussi à analyser les problèmes chez les clients : elle propose des hypothèses et des morceaux de code pour les valider ou les invalider.

On a aussi gagné en agilité pour faire bouger les équipes au sein des projets. Quelqu’un qui maîtrise déjà les fondamentaux de la plateforme et le développement assisté par IA peut prendre en charge plus vite des tâches simples sur un autre projet. Cela nous simplifie la vie quand il faut remplacer un développeur ou réorganiser une équipe.

Quelles limites demandent encore une vigilance particulière ?

Ce n’est pas parce qu’on va plus vite que c’est plus facile. Si l’agent n’est pas suffisamment bien guidé par le développeur, il peut vite se disperser, recréer des éléments inutiles voire omettre des points essentiels autour d’une fonctionnalité métier. La documentation et les ADR sont donc là pour l’aider, mais l’intervention et le cadrage du développeur le sont tout autant.

Sur les interfaces, il peut aussi manquer de créativité si on ne lui donne pas un bon design system, avec des composants et des règles visuelles qui maintiennent l’identité du logiciel et qui permettent surtout de délivrer une UX de qualité. 

Les agents font des erreurs. On a toujours des phases de recette, des retours et des corrections. Cette partie du travail n’a pas tellement changé et le coût des tokens peut vite devenir un sujet.

Pour finir, qu’est-ce que cette nouvelle approche a changé pour la conception d’application ?

Le point de départ reste le même : expliciter les usages et ce qu’on attend de l’application. Jusqu’ici, nous avions surtout concentré l’usage de l’IA sur la réalisation du logiciel. Aujourd’hui, nous sommes en train d’étendre cette logique aux étapes amont, sur l’analyse des besoins et les spécifications fonctionnelles.

L’idée, c’est de coconstruire. On présente les fonctions qu’on veut réaliser, et l’agent pose des questions pour aider à cadrer le besoin à partir de sa connaissance des mécanismes de la plateforme AP4. On peut aussi produire des maquettes beaucoup plus vite, et on est en train d’intégrer cette capacité à nos façons de travailler avec les clients.

Le scénario d’application RH présenté durant le webinar illustre bien cette démarche : on précise qui fait quoi, on manipule une application avec différents comptes et on vérifie les comportements attendus. Les humains valident le résultat, puis on réitère avec les agents si nécessaire. 

Au final, si l’IA transforme la manière de développer des applications métier, son efficacité repose pour beaucoup sur le cadre technique qu’on lui impose et les méthodes de validation.