Comment nous réparons des connecteurs en 15 minutes au lieu de 2 jours

Cet article est le deuxième volet d’une série consacrée à la qualité chez Powens. Nous y expliquons comment nous avons commencé à expérimenter avec des agents IA pour accélérer la maintenance de nos connecteurs. Avec une précision toutefois : nous n’en sommes qu’à nos débuts et ce que vous lisez aujourd’hui peut avoir évolué  rapidement depuis.

Maintenance de la connectivité : pas une correction de bug comme les autres

Comme nous l’expliquions dans notre premier article, les services de connectivité comme Powens (imaginez Zapier, mais pour connecter des comptes bancaires) ont des contraintes de maintenance très particulières.

Powens est, par définition,  un logiciel composé d’un ensemble d’intégrations avec des systèmes externes sur lesquels nous n’avons pas de contrôle : nous importons donc littéralement des centaines de problèmes, qui surviennent de façon aléatoire. Les banques mettent à jour leurs sites. Les API changent sans préavis. À chaque fois, un connecteur casse, et quelqu’un doit le réparer.

Dans notre précédent article, nous décrivions comment nous priorisons les anomalies à corriger en premier. C’est un processus humain classique, qui s’appuie  sur des outils de monitoring avancés. Le système fonctionne bien : il garantit que les vrais problèmes reçoivent de l’attention en priorité. Mais il ne règle pas un problème plus fondamental : la capacité.

Notre équipe de maintenance des connecteurs, X-Connectors, ne peut résoudre qu’une partie du nombre moyen d’anomalies uniques que nous détectons chaque mois. En nous concentrant sur les problèmes qui touchent le plus d’utilisateurs, nous assurons un service stable à 99 % d’entre eux. Mais cela signifie que de nombreuses anomalies restent non corrigées, même si elles ne concernent qu’une poignée d’utilisateurs de banques plus petites. Et c’est, bien sûr, très frustrant pour nous comme pour nos clients.

De plus, comme certains d’entre vous le savent, dès qu’il s’agit de scraping de données financières, les corrections peuvent prendre beaucoup de temps. Reproduire l’erreur est généralement légèrement plus compliqué que pour un bug logiciel classique.

Nos protocoles de sécurité interdisent aux développeurs d’utiliser les identifiants des utilisateurs finaux pour faciliter le débogage. Nous nous appuyons plutôt sur les logs des sessions de navigation et sur une série d’outils internes qui nous aident à localiser le problème. Mais ce n’est pas parfait et, souvent, le débogage se fait par tâtonnements.

D’où la question à un million : un LLM peut-il faire ce travail ? Peut-il nous aider à corriger les problèmes de moindre priorité que nos développeurs n’ont pas la capacité de traiter et, à terme, accélérer aussi la résolution des problèmes prioritaires ?

Deux façons d’aborder un scraper

Quand on pense à appliquer les LLM au web scraping, deux approches radicalement différentes viennent à l’esprit. Et le choix entre l’un ou l’autre révèle assez clairement la façon dont vous abordez l’IA en entreprise. 

La première approche consiste à intégrer le LLM au runtime. À chaque session de scraping d’un site de banque, le modèle interprète le HTML brut et extrait les données à la volée. En somme, le LLM devient une sorte de scraper dynamique. Plus de code rigide à maintenir : le modèle s’adapte dynamiquement à chaque site bancaire et à chaque session de navigation.

Si la banque refond son site du jour au lendemain, le modèle comprend tout simplement la nouvelle mise en page. Zéro interruption. C’est élégant, et cela pourrait être l’avenir de l’extraction de données à long terme.

Mais aujourd’hui, deux obstacles rédhibitoires se dressent :

• D’abord, le coût : une seule session de navigation pilotée par un LLM coûte environ 10 à 20 centimes. Nous rafraîchissons les données des comptes d’un utilisateur (ce que nous appelons une « connexion ») environ 30 fois par mois. Cela représente environ 3 € par connexion, soit plus que ce que nous facturons. Le compte n’y est tout simplement pas.
• Ensuite, le déterminisme : le modèle peut extraire des données légèrement différentes à chaque fois. C’est un vrai problème quand vos clients s’appuient sur des informations financières précises pour faire fonctionner leurs propres produits, ou quand un régulateur vous fait confiance pour fournir les données telles quelles.

	Le LLM comme scraper	Le LLM corrige le code (au développement)
Coût	0,10-0,20 € par session, soit environ 3 € par connexion et par mois	5-15 € une seule fois par correctif
Déterminisme	Variable	Déterministe
Contrôle humain	Aucun	Revue de PR à chaque modification
Adaptation aux refontes	Immédiate	Nécessite un correctif

La seconde approche consiste à garder des connecteurs codés en dur, mais à faire écrire les correctifs par le LLM, comme le ferait un développeur. Le modèle analyse le problème, produit le code et ouvre une pull request. Un développeur humain la relit et la merge.

Avec cette méthode, le coût tombe à 5-15 € par correctif – une dépense ponctuelle, indépendante de la fréquence de rafraichissement des données. Une fois déployé, le code est déterministe. Et chaque modification passe par une revue humaine avant d’arriver en production : nous gardons ainsi un meilleur contrôle.

C’est moins spectaculaire, c’est sûr. Mais Powens gère des millions de connexions bancaires et opère dans un cadre réglementaire strict : la maîtrise de nos processus n’est pas négociable. Nous avons donc fait le choix évident : « le LLM corrige les connecteurs ».

Pour autant, ces deux approches ne s’excluent pas tout à fait. On peut déjà imaginer un modèle hybride, où l’extraction à l’exécution servirait de solution de repli pour les cas limites (les 5 % d’utilisateurs qui tombent sur une mise en page rare), tandis que l’approche par le code gérerait le fonctionnement courant. Mais c’est une autre histoire, pour un autre article.

Enfin ! Un vrai argument en faveur de Woob

L’infrastructure de connecteurs de Powens repose sur Woob, un framework open source que nous développons depuis des années, mais dont se moquent souvent les nouveaux développeurs qui rejoignent Powens. Ils le trouvent obscur, rigide et parfois bien trop lourd pour des tâches simples.

Alors, quand nous avons envisagé pour la première fois de faire écrire du code Woob par une IA, le scepticisme était de mise en interne. Woob n’est pas vraiment grand public. Un modèle de langage pouvait-il comprendre et maîtriser un framework de niche, en tout cas suffisamment pour produire des connecteurs fiables ?

Une première preuve de concept, menée en direct sur un vrai compte bancaire, a tranché le débat assez vite.

Il s’avère qu’un framework structuré est un atout, pas un handicap. Le cœur de Woob gère tout le code répétitif : sessions HTTP, gestion des cookies, pagination, gestion des erreurs. Un connecteur ne contient que la logique propre au site de la banque : quelle page visiter, quels champs extraire, comment naviguer entre les rubriques.

Le LLM travaille donc sur des fichiers courts et bien délimités, plutôt que sur des scripts monolithiques. Et comme tous les connecteurs suivent les mêmes schémas, le modèle peut apprendre les conventions de l’un et les transposer à un autre.

Sans framework, le modèle a tendance à produire du code improvisé : appels HTTP enchaînés, gestion des erreurs au fil de l’eau, navigation en plat de spaghettis. Avec Woob, il produit un code structuré et maintenable, qu’un développeur habitué au framework peut relire en un temps raisonnable. Si vous envisagez une approche similaire pour votre propre code, c’est sans doute l’enseignement le plus important : donnez un cadre au modèle, et la qualité du résultat progresse de façon spectaculaire.

Même méthode, autre joueur

Au final, il nous a fallu quelques mois pour aboutir au premier prototype de notre réparateur de connecteurs par IA. Nous l’avons appelé woob-autofix (un nom pas très original, mais efficace: toute la philosophie Powens)). Son principe de conception est simple : l’agent suit exactement le même workflow qu’un développeur humain.

1. Woob-autofix lit un ticket JIRA.
2. Il récupère le contexte du connecteur depuis nos outils internes.
3. Il reproduit l’erreur en lançant la même commande de diagnostic que nos développeurs.
4. L’agent capture les logs et les réponses HTML, analyse l’échec et écrit un correctif.
5. Il relance le test pour valider.
6. Un agent relecteur distinct et impartial examine le diff sous l’angle de la qualité et de la sécurité. Si la revue relève des problèmes, la boucle recommence.
7. Une fois tous les contrôles passés, une pull request est créée sur GitHub.

Et là, il s’arrête. L’agent ne merge jamais son propre code. L’équipe X-Connectors relit chaque pull request exactement comme n’importe quelle contribution humaine. Là encore, ce choix de conception strict nous paraît évident compte tenu de l’état actuel de l’IA et notre expérience.

Passer un jour à une approche plus souple n’est pas exclu. Mais cela demandera beaucoup d’apprentissage et d’évaluation et, bien sûr, des preuves solides que woob-autofix peut maintenir dans la durée un niveau de performance comparable à celui d’un humain.

Sous le capot, l’agent fonctionne avec Claude via le SDK Claude Code. Au départ, nous faisions tourner Claude Code et Kiro (l’agent de code d’AWS) en parallèle. Mais Kiro n’avait pas de SDK natif : il fallait lancer l’exécutable, parser sa sortie et perdre le contexte entre les étapes. Le SDK Claude Code a permis une intégration fluide dans notre pipeline d’orchestration, avec une continuité complète du contexte. Nous avons fait le choix pragmatique de consolider, et les résultats se sont améliorés.

Au moment de l’écriture du premier draft de cet article nous tournions sous Opus 4.6. A noter que la montée de version depuis 4.5 n’a pas été aussi aisée que prévu. Nos prompts 4.5 étaient un peu trop directifs pour 4.6, qui a besoin d’un peu plus de latitude pour donner de bons résultats. Après un fastidieux travail de réécriture des prompts, les choses se sont améliorées. Désormais, nous maîtrisons mieux ces montées de version. A l’heure de la publication de l’article, nous sommes désormais sur Opus 5.5.

Le plus difficile n’est pas ce que l’on s’imagine

Demandez à n’importe quelle équipe qui développe des outils de développement assistés par IA quel est le plus grand défi, et vous entendrez sans doute souvent « prompt engineering ». C’est vrai, cela représente beaucoup de travail, probablement l’essentiel en volume. Mais ce n’est pas le plus difficile.

Le vrai problème difficile, c’est de savoir si l’on progresse réellement. Dans la plupart des projets logiciels, on mesure la qualité du code généré par l’IA avec des tests unitaires ou des scénarios fixes. Mais c’est beaucoup moins évident avec de la connectivité bancaire: les sites des banques évoluent en permanence. Un cas de test d’il y a trois mois peut viser une mise en page qui n’existe plus, avec la session d’un utilisateur qui a depuis clôturé son compte. Bref, notre cas de test a toujours une date de péremption.

Nous avons donc emprunté une idée à la finance quantitative : le backtesting. Nous remontons le temps, prenons un ticket JIRA vieux de deux mois, récupérons le code tel qu’il était à l’époque, et laissons l’agent tenter la correction. Nous comparons ensuite sa pull request à celle que le développeur humain a réellement livrée. Un juge LLM indépendant évalue les deux solutions au regard de l’énoncé initial du problème.

Cette approche a mis au jour quelque chose que des suites de tests seules n’auraient jamais détecté. Au début, l’agent utilisait une astuce : il « résolvait » les erreurs en interceptant les exceptions au lieu de traiter la cause racine. Plus de plantage, techniquement. Mais plus de données non plus. En comparant avec une référence humaine, le juge sait faire la différence entre un vrai correctif et une rustine.

Au final, où en sommes-nous aujourd’hui ? L’agent produit un correctif au moins aussi bon que celui du développeur dans 25 à 30 % des cas, du premier coup et sans retour de revue. Contre environ 10 % au démarrage. Et nous avons des raisons de penser que nous sous-estimons ce chiffre : les premières revues humaines suggèrent que le juge LLM est trop sévère dans certains cas. Nous menons actuellement des séries de calibrage avec l’équipe X-Connectors.

Même quand le correctif n’est pas parfait, le gain de temps est bien réel. L’agent met 10 à 15 minutes pour corriger un problème. Un développeur, lui, met un à deux jours. Même un correctif qui nécessite des ajustements donne au relecteur une sacrée longueur d’avance. Et n’oublions pas : ces correctifs n’auraient sans doute jamais été fait  sans l’agent – ils auraient tout simplement été dépriorisés. Better done than perfect.

Et parfois, l’IA nous surprend. Dans le bon sens.

Cuand le correctif est bon, il peut être vraiment bon.

Dans un cas, un ticket signalait que plusieurs comptes d’une grande banque française étaient mal typés (autrement dit, nous confondions comptes courants, comptes d’épargne ou autres). L’agent a confirmé le problème puis, sans qu’on le lui demande, a lancé une recherche web sur le nom commercial de chaque compte pour en déterminer le bon type.

Il a identifié un PEA, un compte-titres et d’autres produits, puis a mis à jour le connecteur en conséquence. Un raisonnement purement métier, qu’aucun d’entre nous n’avait explicitement prévu.

Dans un autre cas, un connecteur n’arrivait pas à récupérer les transactions d’un compte précis. L’agent a remarqué que le schéma de l’URL ne correspondait pas à celui des autres pages.

Il s’est donc mis à expérimenter : il a reconstruit l’URL en combinant le nom du compte et le type de produit, a testé plusieurs variantes, en a trouvé une qui renvoyait des données valides, puis a implémenté la logique de parsing. Une démarche d’ingénieur par essais et erreurs, exactement ce que ferait un développeur avec les outils de développement du navigateur ouverts.

Aucun de ces comportements n’était codé en dur. L’agent les a déduits du contexte. Et c’est précisément ce qui rend cette approche prometteuse : ce n’est pas un script avec mille règles. C’est un modèle qui raisonne sur les problèmes.

Tous les clients de l’agrégation bénéficient de ce développement. Lors du dernier sprint, nous avons consacré 40 % de temps en moins à la maintenance et plus que doublé la qualité des connecteurs de dernier niveau (leur taux de réussite est passé de 27 % à plus de 60 %). D’ici six mois, les clients peuvent s’attendre à des délais de résolution nettement plus courts pour les incidents de connecteurs et à une meilleure qualité de service au quotidien. – Vincent Paredes, Powens VP AI & Technology 

La suite du chemin

Aujourd’hui, woob-autofix prend en charge les connecteurs de scraping de la verticale Wealth (comptes d’épargne et d’investissement, non couverts par les API DSP2). Nous avons commencé à l’étendre aux connecteurs DSP2, en commençant par les problèmes de typage des comptes. La récupération des documents devrait suivre rapidement.

La grande avancée à venir, c’est la navigation. Actuellement, l’agent ne peut travailler qu’avec les pages que le connecteur connaît déjà, du moins dans la plupart des cas. Nous développons donc un accès contrôlé au navigateur pour que l’agent puisse découvrir de nouvelles pages de manière autonome, avec des restrictions strictes.

Plus tard, nous voulons boucler complètement la boucle. Aujourd’hui, l’agent traite des tickets JIRA : des problèmes déjà détectés, qualifiés et remontés par des humains. Mais notre monitoring capture déjà les plantages en temps réel. Imaginez : une banque déploie un changement bloquant à minuit. L’agent détecte l’erreur, propose un correctif et ouvre une PR. Un développeur la relit à 9 h. À 10 h, le connecteur fonctionne de nouveau. C’est vers là que nous allons.

Enfin, nous expérimentons déjà le pendant de la réparation des connecteurs : leur création. Imaginez que toute demande d’un client (ou d’un utilisateur final) pour connecter une banque ou une plateforme très spécifique, pas encore prise en charge, puisse être satisfaite en une heure. Bientôt, ce ne sera peut être plus de la science-fiction.

Conclusion : garder l’IA sous contrôle est un bon point de départ

Vous l’aurez compris, nous ne remplaçons pas les développeurs par l’IA. Nous leur donnons un levier. L’équipe X-Connectors relit toujours chaque correctif, reste propriétaire du code et garde la main sur les décisions. Mais au lieu de passer deux jours sur une modification de parsing, elle peut consacrer quinze minutes à relire une pull request bien structurée, et réorienter son expertise vers des tâches plus complexes et à plus forte valeur. Et elle se réjouit de savoir que, enfin, certains problèmes de moindre priorité seront traités.

Dans notre secteur, la confiance est primordiale. Nos clients dépendent de nous pour des données financières critiques. C’est pourquoi nous avons choisi l’approche qui garde l’humain aux commandes tout en utilisant l’IA là où elle excelle : la vitesse, la reconnaissance de schémas et l’itération infatigable. C’est la même philosophie qui guide notre système de priorisation par niveaux, notre monitoring et tout ce que nous construisons. Faire le travail difficile. Être transparents. Et ne jamais transiger sur les contrôles.