Devoxx : le Crédit Agricole conjugue IA, Clean Code et qualité logicielle

Lors de la présentation « L'IA dans le cycle de vie logiciel : quelles opportunités, quelles limites ? », Raphaël Uzan, Lead Data/AI Engineer au sein de Crédit Agricole S.A., a d’abord replacé l’IA dans une trajectoire déjà engagée au sein du groupe. Les usages ne se limitent plus à quelques projets spécialisés. Ils couvrent désormais la détection de fraude, l’OCR (Optical Character Recognition, reconnaissance optique de caractères), la validation automatique de factures, les chatbots, les outils de synthèse documentaire et les assistants au développement.

Cette progression transforme directement le SDLC (Software Development Lifecycle, cycle de vie du développement logiciel). L’IA peut intervenir dans la formalisation du besoin, le design fonctionnel, l’architecture technique, la génération de code, les tests, le déploiement, la maintenance et le monitoring. Dans un groupe bancaire, cette extension reste cependant encadrée par une exigence de fiabilité. Raphaël Uzan l’a formulé ainsi : « En dix ans, l’IA est passée des salles de serveurs aux postes de travail de chaque collaborateur. »

Cette diffusion ne peut donc pas se réduire à une logique de productivité individuelle. Elle suppose une intégration dans les chaînes de développement, avec des standards, des contrôles et une responsabilité assumée par les équipes IT. Le sujet porte autant sur l’efficacité que sur la capacité à préserver la confiance dans les systèmes produits.

Formaliser le besoin avant d’automatiser

Ghizlane Pacheco, Senior Business Analyst/Data Product Owner au sein de Crédit Agricole Corporate & Investment Bank, a ensuite abordé les premières étapes du cycle logiciel. Son intervention part d’un constat opérationnel : beaucoup de difficultés apparaissent avant même l’écriture du code. Les exigences peuvent rester ambiguës, les contraintes fonctionnelles ou non fonctionnelles peuvent manquer de précision, les pratiques peuvent diverger entre équipes et la documentation peut perdre sa valeur au fil du temps.

L’IA peut aider à traiter ces fragilités si elle s’appuie sur une analyse rigoureuse. Ghizlane Pacheco a présenté l’usage d’agents spécialisés pour produire des documents de type PRD (Product Requirements Document, document d’exigences produit) ou BRD (Business Requirements Document, document d’exigences métier). Ces livrables servent à décrire l’intention, la valeur attendue, le périmètre, les utilisateurs concernés et les critères d’acceptation.

La démarche repose sur un échange itératif. L’agent part d’une intention, pose des questions de clarification, reçoit des réponses humaines puis affine le document. La validation ne disparaît pas : elle devient une étape de contrôle et d’arbitrage. Ghizlane Pacheco a insisté sur ce point : « La révision humaine, présente à chaque étape du processus, constitue notre premier garant de qualité ».

Cette logique se prolonge dans le design fonctionnel et technique. Un modèle peut proposer une architecture cohérente, mais celle-ci doit intégrer le catalogue technologique de l’entreprise, les règles d’architecture, les bonnes pratiques de backlog et la « definition of ready » (critères qui indiquent qu’un élément peut entrer en développement). Sans ce contexte, l’IA risque de produire une réponse plausible, mais inadaptée au système d’information réel.

Des agents intégrés aux outils des développeurs

Aïssa Bouhadjar, Tech Lead chez LCL, a illustré l’intégration de l’IA dans l’outillage quotidien des équipes. À partir d’une user story bancaire, par exemple le blocage instantané d’une carte en cas de perte, un agent peut générer des critères d’acceptation et des scénarios Gherkin. Gherkin désigne un langage de description des comportements attendus d’une application, souvent utilisé en BDD (Behavior-Driven Development, développement piloté par le comportement). Il formalise les scénarios sous une forme lisible par les métiers, les testeurs et les développeurs, avec une structure du type « Étant donné », « Quand », « Alors ».

L’intérêt réside dans la connexion avec les outils existants. Les agents peuvent récupérer des tickets dans Jira, enregistrer des scénarios dans Octane, exploiter le contexte d’un projet dans VS Code et interagir avec certains environnements via MCP (Model Context Protocol, protocole permettant à un modèle d’accéder à des outils ou à des ressources contrôlés). Aïssa Bouhadjar a rappelé la nécessité d’un contrôle humain : « Les scénarios générés peuvent se révéler corrects ou non, selon les critères de l’opérateur ou du demandeur. Le principe du ‘human in the loop’, qui correspond à une validation humaine, intervient ensuite pour assurer leur pertinence »

Cette logique couvre aussi le développement. Les agents peuvent produire ou enrichir un plan de développement, un README, une documentation technique, du code source, des tests unitaires et des tests d’intégration. Dans une chaîne CI/CD (Continuous Integration / Continuous Delivery, intégration continue et livraison continue), ils peuvent intervenir lors d’une pull request (demande de revue et d’intégration de modifications de code dans un projet logiciel) pour proposer des améliorations. La décision finale reste confiée aux développeurs, notamment lorsque les enjeux touchent à la sécurité, à la conformité ou à la qualité de production.

Le Clean Code comme garde-fou face à l’accélération

La facilité de production comporte cependant un risque : générer davantage de code peut accroître la charge de revue, de compréhension et de maintenance. Raphaël Uzan a résumé cette limite par une formule nette : « Le piège tient précisément à cette facilité de production, qui peut donner une illusion de maîtrise. »

La conférence « Clean Code Matters », présentée par Marc Lecanu, Software Engineer chez LCL, répond directement à cet enjeu. Son intervention rappelle qu’un code ne vaut pas seulement parce qu’il fonctionne. Il doit pouvoir être lu, compris, modifié et maintenu par d’autres membres de l’équipe. À travers un exemple fondé sur une méthode de tri de Pokémon, Marc Lecanu montre qu’un code apparemment simple peut masquer un comportement erroné si le nommage, l’intention et les tests ne convergent pas.

Le Clean Code ne relève donc pas d’une préférence esthétique. Il constitue une discipline collective. Marc Lecanu en donne une définition opérationnelle : « Le Clean Code désigne un code lisible et maintenable par tout membre de l’équipe ». Cette approche commence par le nommage. Un nom doit révéler l’intention et apporter du contexte. Les termes trop génériques affaiblissent la compréhension. Les valeurs codées en dur doivent être remplacées par des constantes ou des énumérations explicites.

Les fonctions exigent la même vigilance. Une fonction trop longue signale souvent un périmètre trop large. Un nombre excessif d’arguments complique l’usage. Les booléens peuvent indiquer que plusieurs comportements cohabitent dans une même méthode. Marc Lecanu rappelle aussi deux principes simples : KISS (Keep It Simple, garder une solution simple) et DRY (Don’t Repeat Yourself, éviter la duplication). Dans un contexte où l’IA peut produire rapidement des variantes de code, ces garde-fous limitent la dispersion de la logique applicative.

Des principes de conception jusqu’à la responsabilité en production

Marc Lecanu a également présenté les principes SOLID, qui visent à rendre le code plus facile à maintenir et à faire évoluer. Ces principes encouragent à limiter les responsabilités de chaque classe, à ajouter des fonctionnalités sans modifier l’existant, à éviter les dépendances trop rigides et à utiliser des interfaces adaptées aux besoins réels du logiciel.

Ces principes rejoignent les messages portés dans la conférence sur l’IA. Un agent peut accélérer certaines tâches, mais la qualité dépend toujours des règles de conception, des tests et des revues. Marc Lecanu insiste sur les tests unitaires, les tests d’intégration, les tests end-to-end, les tests de charge, le TDD (Test-Driven Development, développement piloté par les tests), les contrôles de couverture et les scans de dépendances destinés à détecter des vulnérabilités.

Les deux conférences convergent ainsi vers une même conclusion : l’IA augmente la capacité d’exécution des équipes, mais elle renforce aussi les exigences d’ingénierie. Le Crédit Agricole présente une approche où agents, spécifications, Clean Code, tests, CI/CD et gouvernance ne constituent pas des sujets séparés. Ils forment les conditions d’un cycle logiciel plus rapide, sans renoncer à la lisibilité, à la maintenabilité et à la qualité attendues dans un environnement bancaire.