{"id":26286,"date":"2025-11-18T11:23:59","date_gmt":"2025-11-18T10:23:59","guid":{"rendered":"https:\/\/powenscom.bigscoots-staging.com\/?p=26286"},"modified":"2026-05-06T16:33:16","modified_gmt":"2026-05-06T14:33:16","slug":"tiering-connecteurs-priorisation-anomalies","status":"publish","type":"post","link":"https:\/\/www.powens.com\/fr\/tiering-connecteurs-priorisation-anomalies\/","title":{"rendered":"Priorisation et hi\u00e9rarchisation des connecteurs chez Powens"},"content":{"rendered":"\n

Cet article est le premier d\u2019une s\u00e9rie d\u00e9di\u00e9e \u00e0 la qualit\u00e9 chez Powens. Dans celui-ci, nous explorons notre cadre de priorisation des anomalies.<\/em><\/p>\n\n\n\n

Il \u00e9tait une fois les bugs<\/h2>\n\n\n\n

La plupart des ing\u00e9nieurs s\u2019accorderont \u00e0 dire qu\u2019aucune machine n\u2019est parfaite \u2014 surtout dans le logiciel. Les bugs font partie de l\u2019\u00e9quation et existeront toujours. Les logiciels sont des syst\u00e8mes complexes, et l\u2019exp\u00e9rience confirme syst\u00e9matiquement le th\u00e9or\u00e8me de Derrick<\/a> : plus un syst\u00e8me est complexe, plus la probabilit\u00e9 qu\u2019il \u00e9choue est \u00e9lev\u00e9e.<\/p>\n\n\n\n

Vous pouvez opter pour une politique de \u201cz\u00e9ro bug\u201d<\/a>. Cela signifie essentiellement ne pas livrer de nouveau code tant que tous les bugs connus, m\u00eame mineurs, ne sont pas corrig\u00e9s. Cette approche peut fonctionner si votre logiciel est peu complexe et n\u2019a que tr\u00e8s peu de d\u00e9pendances externes (par exemple, si les bugs sont majoritairement endog\u00e8nes et non dus \u00e0 des tiers).<\/p>\n\n\n\n

Mais d\u2019un point de vue business, cela peut s\u2019av\u00e9rer une erreur strat\u00e9gique. Comme d\u2019autres industries n\u00e9cessitant beaucoup d\u2019investissements avant de viser la profitabilit\u00e9, le logiciel est soumis \u00e0 des dynamiques de monopole <\/strong>\u2014 surtout lorsqu\u2019il b\u00e9n\u00e9ficie d\u2019effets de r\u00e9seau<\/a>. Aujourd\u2019hui, une poign\u00e9e de g\u00e9ants de la tech repr\u00e9sente 30 % de la valeur du S&P<\/a>. Mais contrairement \u00e0 des secteurs traditionnels comme le p\u00e9trole ou la pharma, les barri\u00e8res \u00e0 l\u2019entr\u00e9e sont plus faibles dans le logiciel, et le rythme d\u2019innovation y est fulgurant. En clair, quelques d\u00e9veloppeurs talentueux peuvent rapidement devenir des concurrents s\u00e9rieux \u2014 en particulier si votre produit est peu diff\u00e9renci\u00e9. Pour garder votre avance, vous devez donc investir en continu dans de nouvelles fonctionnalit\u00e9s et de nouveaux produits<\/strong>.<\/p>\n\n\n\n

L\u2019Open Banking, justement, coche plusieurs de ces cases. Il repose sur de nombreuses d\u00e9pendances externes<\/a> (connecteurs vers des APIs et des sites bancaires), est ultra-concurrentiel et assez banalis\u00e9 \u2014 les produits concurrents se ressemblent beaucoup. Les effets de r\u00e9seau sont cruciaux, car les clients choisissent souvent le fournisseur qui couvre le plus grand nombre de banques. Et pour ne rien arranger, les APIs bancaires et les sites auxquels nous nous connectons sont loin d\u2019\u00eatre des mod\u00e8les de stabilit\u00e9.<\/p>\n\n\n\n

En th\u00e9orie, cela devrait conduire \u00e0 un taux d\u2019anomalies sup\u00e9rieur \u00e0 celui d\u2019autres produits logiciels. Et pourtant, ce n\u2019est pas vraiment le cas. Voici pourquoi.<\/p>\n\n\n\n

Ce que cela signifie pour Powens<\/h2>\n\n\n\n

Avant d\u2019entrer dans le d\u00e9tail, un mot sur le vocabulaire : chez Powens, on \u00e9vite de parler de \u201cbugs\u201d, car la majorit\u00e9 de nos anomalies sont import\u00e9es \u2014 elles ne sont pas dues \u00e0 un d\u00e9faut dans notre code, mais \u00e0 un \u00e9v\u00e9nement ext\u00e9rieur que nous ne contr\u00f4lons pas.<\/p>\n\n\n\n

Maintenant que les termes sont pos\u00e9s, passons aux chiffres. Powens maintient aujourd\u2019hui 5 millions de connexions bancaires actives*<\/strong> en Europe et en Am\u00e9rique latine, et en ajoute chaque mois entre 50 000 et 100 000. En un mois, notre syst\u00e8me de monitoring remonte en moyenne 30 000 anomalies sur diff\u00e9rents types de connexions (ex. : un seul compte non rafra\u00eechi ou une banque enti\u00e8re indisponible pour certains utilisateurs). Cela repr\u00e9sente un taux d\u2019erreur de 0,6 %, soit 99,4 % de succ\u00e8s \u2014 une tr\u00e8s bonne performance pour un produit connect\u00e9 \u00e0 plus de 1\u202f800 sources de donn\u00e9es externes.<\/p>\n\n\n\n

Si l\u2019on regroupe ces anomalies par causes racines uniques, cela donne environ 500 probl\u00e8mes uniques par mois, soit 1,2 d\u00e9faut par KLOC<\/a> (1 000 lignes de code) \u2014 une norme \u00e9quivalente \u00e0 celle des meilleurs syst\u00e8mes d\u2019entreprise. En termes absolus, notre niveau de qualit\u00e9 est donc \u00e9lev\u00e9<\/strong>, voire exceptionnel si l\u2019on consid\u00e8re que la majorit\u00e9 de nos anomalies provient de l\u2019ext\u00e9rieur. Mais nos clients, \u00e0 juste titre, ne jugent pas en absolu.<\/p>\n\n\n\n

En relatif, la situation est diff\u00e9rente : notre \u00e9quipe peut corriger environ 100 anomalies par mois, laissant 400 anomalies non r\u00e9solues \u2014 soit un taux de correction d\u2019environ 20 %.<\/p>\n\n\n\n

* Une connexion bancaire d\u00e9signe une liaison de donn\u00e9es sp\u00e9cifique \u00e9tablie entre un utilisateur final (particulier ou entreprise) et sa banque. Une seule connexion bancaire peut donner acc\u00e8s \u00e0 plusieurs comptes bancaires si l\u2019utilisateur poss\u00e8de plusieurs comptes dans cette banque sp\u00e9cifique.<\/em><\/p>\n\n\n\n

Que faire dans ce cas ?<\/h3>\n\n\n\n