Checkmarx, ou l’éloge du Tokenmaxxing contrôlé

50 % de code en plus

De passage à Paris, son CPO, Jonathan Rende, s’est confié en petit comité sur ses recettes internes pour développer ses produits à l’ère de l’IA – une technologie qui fait qu’aujourd’hui, ses équipes écrivent 50 % de code en plus qu’avant l’IA.

« Les budgets augmentent parce que nous essayons d’encourager nos équipes », confirme-t-il. « Dans toute organisation, il y a ceux qui veulent apprendre et utiliser, et ceux qui ne le veulent pas. Moi, je veux encourager ceux qui apprennent. »

Quitte à ce qu’il y ait des ratés. « Maintenant, ils font peut-être des choses idiotes et il y a peut-être du gaspillage. C’est un risque que je prends pour l’instant. Mais nous approuvons tout. On verra bien ce qui se passera ensuite », lance-t-il.

« Dans toute organisation, il y a ceux qui veulent apprendre et essayer, et les autres. Moi, je veux encourager ceux qui apprennent. »

Cette approche « open-bar » se justifie aussi par le fait que le responsable constate qu’il y a de nombreux bénéfices réels à l’IA.

« La totalité du cycle de développement a radicalement changé. Tout s’est accéléré avec Claude Code », témoigne-t-il. « Mes équipes produit l’utilisent pour la conception et pour les spécifications. Et certains de mes product managers font désormais des pull requests qu’ils proposent aux équipes d’ingénierie pour les aider ».

L’IA a déjà transformé le rôle même de l’ingénieur chez Checkmarx. Il est passé du codage à celui d’architecte logiciel.

Du code à superviser

En contrepartie, le code n’est pas forcément plus sûr. « Quand on regarde les benchmarks sur la qualité, l’efficacité et la sécurité du code généré, on trouve entre 40 et 80 % de code non sécurisé. Cela dépend d’où l’on regarde », prévient Jonathan Rende. « Les modèles s’amélioreront avec le temps, mais ils n’y sont pas encore », avance-t-il.

L’IA est en fait bonne pour repérer trois catégories de vulnérabilités. « La logique métier, les IDOR et les vulnérabilités en chaîne », liste le CPO. « En revanche, elle n’est pas bonne pour trouver les problèmes connus, les CWE autour du cross-site scripting, l’injection SQL, tous les cas déjà répertoriés […] Et beaucoup de failles faibles ou moyennes s’enchaînent pour en former une bien plus critique. »

Il faut donc impérativement garder l’humain (ici, l’expert) dans la boucle.

« Quand on regarde les benchmarks sur la qualité, l’efficacité et la sécurité du code généré, on trouve entre 40 et 80 % de code non sécurisé. »

L’IA apporte également des gains dans la prise en charge de technologies éparses. Mais là encore avec une limite. « Nous avons beaucoup de langages et de frameworks en interne. Certaines équipes sont bonnes en Java, d’autres en Go ou dans un autre langage », narre Jonathan Rende. L’IA permet à présent de passer de l’un à l’autre. « Mais il reste une connaissance propre à chaque code. On peut générer un tas de pull requests dans un langage que l’on ne maîtrise pas, mais elles doivent quand même être relues par les experts du domaine, pour savoir si elles vont créer des problèmes », nuance le CPO.

Et là encore, un encadrement est indispensable.

« C’est un travail interne en cours », répond-il au MagIT. Des choses sont cependant déjà mises en place. Pour mieux contrôler la qualité et la sécurité, Checkmarx utilise par exemple logiquement ses propres agents IA de relecture du code (dans une logique de dog fooding). Pour contrôler le foisonnement, il a commencé à mutualiser les « skills ». « Si vous voulez partager un fichier de skill, il doit aller dans le dépôt central » où il est analysé et répertorié, tranche le CPO.

L’IA a aussi changé le calendrier de développement. « Avant, j’avais des plans à deux ans. Nous sommes passés à une planification annuelle. Et nous réévaluons au début de chaque trimestre, parce que beaucoup de choses changent très vite aujourd’hui », justifie-t-il.

200 dollars de token par dev, mais pas de vraie limite

Quant au budget alloué à chaque développeur, il est environ de 200 $ en tokens. Mais le CPO assure qu’il ne regarde même pas les demandes de dépassements. « Je reçois cinq mails par jours, et je fais juste “ok, ok, ok, ok, ok” », sourit-il.

Cette approche très conciliante, favorisée par le fait que la volonté de pousser l’IA est venue du CEO, n’empêche cependant pas Jonathan Rende de regarder ce qui est produit. « Mon pire cauchemar serait que notre base de code augmente de 50 %, mais que notre productivité n’augmente pas », confie-t-il, « Que nous créions plus d’erreurs. »

« La motivation d’Anthropic, c’est de vendre plus de tokens. Ils se moquent de savoir si le code est bon ou mauvais. »

Aujourd’hui, le CPO ne vérifie donc pas ce que fait chaque développeur, mais il regarde l’ensemble. « Nous avons mis en place un ensemble de métriques pour le département ingénierie et produit », esquisse-t-il. « Côté produit, je veux savoir combien d’exigences sont renvoyées par l’ingénierie ». Ces exigences sont dans les « product requirement documents » (PRD) qui servent à définir les investissements. « Nous les écrivions à la main ; maintenant nous utilisons l’IA. » Si l’ingénierie en renvoie beaucoup, c’est le signe que les documents générés sont de piètre qualité.

Sur la qualité justement, Jonathan Rende veut aussi s’assurer qu’il ne produit pas du « slop code ». « Nous pouvons créer un tas de code, mais je ne sais pas s’il est efficace et s’il a une vraie valeur. J’ai donc aussi mis en place un ensemble de métriques pour savoir comment nous nous en sortons et si nous progressons ».

Tokenmaxxing, oui, mais pas « no control » donc. Car le CPO n’est pas dupe non plus de la logique de son fournisseur principal, qui est aussi un partenaire depuis qu’il a intégré sa marketplace. « La motivation d’Anthropic, c’est de vendre plus de tokens. Ils se moquent de savoir si le code est bon ou mauvais », glisse-t-il.

Arriver à vendre des résultats, pas des tokens

Le contrôle est d’autant plus important que Checkmarx utilise également l’IA dans son produit avec la logique inverse d’Anthropic. Il ne facture pas au token. Mais il ne facture plus non plus par licence (par siège/développeur) sur l’IA. « Nous facturons aux résultats (triage, scan réussi, remédiation, etc.) au travers de “crédits” », précise Florent Mauzé, Country Manager France Benelux de l’éditeur. « Par exemple, un crédit vaut un triage. Trois crédits valent une remédiation. »

Un autre défi est donc d’optimiser l’usage interne des LLMs, non plus pendant le développement, mais lors de l’inférence cette fois. « L’IA est un vrai coût pour nous », acquiesce Jonathan Rende. « Nous essayons de le réduire au minimum ».

« Une facturation prévisible est un des principaux sujets dont les clients nous parlent. »

L’optimisation passe par le routage des modèles en fonction des tâches et par des « harness ». Les LLMs sont aussi évalués en interne. « Nos benchmarks sont très importants. Avant de déployer de nouveaux modèles, ils y passent tous », insiste le CPO. « Nous avons environ 10 millions de lignes de code issues de projets open source qui nous permettent de tester en permanence les performances sur de nombreux paramètres. »

Tous ces éléments permettent de contrôler les coûts variables de l’IA derrière des « crédits » fixes, et donc de garder une marge. Or ces crédits fixes sont hautement stratégiques, car ils permettent de garder une facturation prévisible. « C’est un des principaux sujets dont les clients nous parlent », relève Florent Mauzé.

Ne pas freiner les tokens en interne. Les compter un à un pour le client. Les deux démarches sont donc moins contradictoires qu’il n’y paraît. Et elles ont un point commun pour être de « bons chasseurs » : mesurer ce que rapporte chaque dépense IA, que ce soit pour le produit ou pour le client.

Entretien réalisé en octobre 2026 à Paris.