Alexandre Grais (Kapptivate) décrypte les angles morts de la prod, des tests end-to-end aux agents IA.
Cet article est tiré de l'épisode du podcast Prod'Way avec Alexandre Grais, cofondateur de Kapptivate. A écouter sur Deezer, Apple Podcast, Spotify ou Acast.
Il y a une scène qui revient souvent dans la vie d'un responsable de production : une réunion tendue, des métiers qui tapent du poing sur la table parce que "ça ne marche pas", et en face, une DSI qui ouvre ses dashboards et répond, un peu gênée : "Pourtant, tout est au vert de notre côté." Deux vérités qui se regardent en chiens de faïence, et personne qui sort gagnant.
Ce décalage entre ce que mesure la technique et ce que vit l'utilisateur, c'est le point de départ de notre conversation avec Alexandre Grais, co-fondateur et CEO de Kapptivate, plateforme de tests end-to-end automatisés née dans le mobile money africain et devenue un outil de supervision continue pour des grands comptes du télécom, de la banque et de l'assurance. Mais au fil de l'épisode, un thème beaucoup plus large a émergé : celui de la capacité à sentir, tôt, les signaux qui annoncent un problème. Dans la prod comme dans vie pro ou perso.
Dans les grandes organisations, les outils d'observabilité ne manquent pas. Datadog, Dynatrace, Splunk, sans compter les couches internes : on mesure les CPU, les latences réseau, les erreurs applicatives, les métriques business. Sur le papier, tout est surveillé. Dans la pratique, pourtant, ce sont souvent les clients qui détectent les incidents en premier.
Alexandre l'a vécu très tôt, dès ses années chez Orange, où il déployait des solutions de paiement mobile en Afrique. Malgré un arsenal impressionnant d'outils de supervision, les problèmes remontaient du terrain avant d'apparaître dans les alertes. Pourquoi ? Parce que tous ces outils observent le système, pas le parcours. Ils surveillent la tuyauterie, pas ce que voit la personne qui clique.
Le problème prend une dimension vertigineuse dans les architectures modernes. Un flux aussi banal que souscrire une offre ou signer un document traverse aujourd'hui dix briques applicatives, quatre équipes, parfois plusieurs SI historiques et une solution de signature électronique externe. Chacun surveille son morceau. Personne ne surveille la chaîne. Le CTO d'une des plus grandes banques européennes a confié récemment à Aimery : "On a identifié les 30 process les plus critiques de la banque, mais on ne sait pas, de façon centralisée, monitorer s'ils fonctionnent de bout en bout."
C'est précisément cette zone aveugle que Kapptivate adresse : simuler, en continu, des parcours réels d'utilisateurs, avant, pendant et après la mise en production. Et surtout, rendre ces tests lisibles par tout le monde. Parce que le vrai bénéfice n'est pas technique, il est organisationnel : quand IT et métiers regardent le même écran et voient la même vérité, les débats stériles du "ça marche / ça marche pas" s'arrêtent net.
Si le test de bout en bout est une si bonne idée, pourquoi si peu d'organisations le font sérieusement ? Alexandre donne le chiffre qui tue : dans un projet de test E2E, 20 % du coût c'est la création initiale, 80 % c'est la maintenance dans la durée. Et c'est là que la majorité des démarches s'enlisent.
Le coupable est connu de tous ceux qui ont essayé : la dépendance à l'interface graphique. Un bouton qui passe de "Me connecter" à "Se connecter", un champ qui change de position, une couleur qui bascule — et le test s'arrête. Pendant des années, l'industrie a tenté de contourner ce problème à coups de bonnes pratiques de développement, de test IDs posés sur chaque élément, de design systems disciplinés. Ça marchait quand on maîtrisait tout le code. Ça ne marchait presque jamais en vrai.
Ce qui change aujourd'hui, ce sont les modèles de vision et les LLM multimodaux. Un test qui s'appuie sur une compréhension visuelle et sémantique de la page — "clique sur le bouton qui permet de se connecter, peu importe sa forme ou son texte" — devient beaucoup plus résilient aux changements d'interface. C'est une forme de fiabilité qu'on attendait depuis quinze ans, et qui n'arrive que maintenant. Ce qui était une promesse marketing devient une réalité industrielle.
La conversation glisse alors vers un terrain qui touche toutes les DSI : que deviennent les équipes quand un développeur peut produire, avec un agent de coding bien piloté, ce qu'il produisait autrefois en deux semaines ? Alexandre ne théorise pas : il raconte. Chez Kapptivate, tous les développeurs sont équipés depuis janvier. Lui-même, qui n'avait pas touché au code depuis cinq ans, a livré deux features en quelques jours. Pas du prototype jetable — du code en production, revu par ses pairs.
Mais le vrai changement n'est pas la productivité. C'est la nature du métier. On ne demande plus à un développeur d'écrire des lignes de code : on lui demande de piloter une spécification. De découper un problème, de le structurer, de l'expliciter suffisamment pour que l'agent produise quelque chose d'exploitable en un seul coup. C'est un profil hybride, à mi-chemin entre le dev et le product owner, qu'Alexandre appelle le product builder.
Les conséquences organisationnelles sont massives. Le split front/back commence à s'estomper : avec une bonne bibliothèque de composants bien documentée, un dev back peut toucher au front et inversement. Les squads de 8 personnes pourraient demain en compter une ou deux. Les tribus de 200 pourraient se fractionner en six tribus de dix. Et là où la coordination de 200 personnes posait déjà problème, comment synchroniser six entités qui vont chacune trois fois plus vite ? Personne n'a la réponse. Alexandre insiste sur ce point avec lucidité : nous sommes dans une phase d'expérimentation. Les bonnes pratiques de début janvier ne sont déjà plus celles de février. Il faut tester, observer, ajuster — et l'admettre.
C'est sur ce terrain du "comment on tient la cadence" que l'épisode bascule, presque naturellement, vers un registre plus personnel. En janvier 2020, sur une plage d'Afrique du Sud, à six heures de route d'un hôpital, Alexandre fait une crise cardiaque. Il a 31 ans. Aucun facteur physique ne l'expliquait : pas de cholestérol, pas de signal médical. Le verdict est tombé plus tard : c'était le stress.
Ce qui est frappant dans son récit, ce n'est pas le drame lui-même — c'est ce qu'il en a tiré. Il n'a pas ralenti ; il a appris à écouter. Il a construit, petit à petit, un système de signaux internes qui lui permet de détecter ses montées de tension avant qu'elles ne deviennent critiques. Sa formulation est restée gravée : "s'auto-monitorer, sentir l'orange avant le rouge."
La métaphore n'est pas anodine. C'est exactement ce que Kapptivate essaie de faire pour les systèmes : capter les signaux faibles avant qu'ils ne deviennent des incidents visibles. La boucle se referme. Ce que la Prod cherche depuis toujours — une supervision qui anticipe plutôt qu'elle ne constate — est ce qu'un dirigeant sous pression doit apprendre à faire pour lui-même. Et Alexandre pose en passant un sujet dont on parle trop peu : la solitude du responsable de prod. On parle volontiers de la solitude du dirigeant ; celle du Head of Run mérite la même attention. Porter la responsabilité de ce que d'autres ont produit, jour et nuit, use autrement — et mériterait des groupes de pairs aussi structurés que ceux des entrepreneurs.
Au fond, cet épisode raconte une seule chose, déclinée en trois échelles : la technique, l'organisation, l'humain. Dans les trois cas, la question est la même — sommes-nous capables de voir venir ? Un dashboard vert qui ment, une tribu qui ne sait plus se synchroniser, un corps qui envoie des signaux qu'on n'écoute pas : ce sont les trois visages d'un même angle mort.
La bonne nouvelle, c'est que ces angles morts sont adressables. À condition de changer d'angle, justement. De regarder depuis l'utilisateur plutôt que depuis la machine. D'accepter que l'organisation d'hier ne colle plus. Et de se rappeler qu'un pilote efficace est d'abord un pilote qui s'écoute.
Alors, votre prod est au vert ? Peut-être. Mais au vert pour qui, exactement ?
