Gautam Korlam, ingénieur principal chez Sonar – Série d’interviews

Gautam Korlam, ingénieur principal chez Sonar, est un ingénieur logiciel chevronné et un leader technologique dont la carrière s’est concentrée sur l’infrastructure développeur, la qualité du code, l’automatisation et le développement logiciel assisté par l’IA. Avant de rejoindre Sonar, il a co‑fondé Gitar et a occupé le poste de CTO, créant une plateforme native IA conçue pour automatiser la revue de code, diagnostiquer les échecs d’intégration continue (CI), identifier les causes profondes et générer des correctifs. Sonar a acquis Gitar en mai 2026, avec Korlam et l’équipe de Gitar rejoignant l’entreprise pour poursuivre le développement de la technologie au sein de la plateforme de vérification de code plus large de Sonar. Avant Gitar, Korlam a passé près d’une décennie chez Uber, passant d’ingénieur fondateur de l’équipe plateforme mobile à ingénieur principal. Au cours de son mandat, il a contribué à construire et à faire évoluer l’infrastructure développeur centralisée d’Uber, a dirigé d’importantes initiatives monorepo et de système de construction, a développé des environnements de développement à distance et des outils CI/CD, et a expérimenté avec des modèles de langage de grande taille open‑source tels que StarCoder, OctoCoder et Code Llama afin d’améliorer le codage assisté par IA dans le code d’Uber. Ses expériences antérieures comprennent des postes d’ingénierie chez Lookout, des travaux de recherche à l’Université de Californie, Santa Barbara, ainsi que des stages chez Microsoft et Oracle.

Sonar est une société de logiciels spécialisée dans la vérification de code, la revue de code automatisée, la qualité du code et la sécurité des applications. Sa plateforme phare SonarQube analyse le code écrit par les développeurs et le code généré par l’IA afin d’identifier les bugs, les vulnérabilités, les problèmes de maintenabilité et autres défauts de qualité avant qu’ils n’atteignent la production, avec des offres couvrant le cloud, les déploiements auto‑gérés et les flux de travail d’environnement de développement intégré. Sonar affirme que sa technologie est utilisée par plus de 7 millions de développeurs et 22 000 clients, et qu’elle analyse chaque jour plus de 750 milliards de lignes de code. L’acquisition de Gitar a élargi cette approche vers la revue et la remédiation de code natives IA, combinant le moteur de vérification de SonarQube avec des outils agents capables de revoir le code, d’enquêter sur les échecs de CI et de proposer ou d’appliquer des correctifs à mesure que le développement logiciel devient de plus en plus piloté par l’IA.

Votre carrière vous a conduit de la construction de l’infrastructure mobile et développeur d’Uber à la formation de modèles de langage ouverts sur son code, avant de co‑fonder Gitar et de rejoindre Sonar suite à son acquisition. Comment ces expériences ont‑elles façonné votre conviction que la génération de code n’est qu’une partie du défi, et que la validation fiable du code est probablement le problème le plus difficile ?

Chez Uber, je travaillais sur les parties du système qui décident si quoi que ce soit est déployé : le monorepo, la construction, la file d’attente CI, la suite de tests. Rendre la production de changements plus facile met toute la pression sur cette machinerie. Vous obtenez davantage de services qui interagissent de façons imprévues, et davantage d’ingénieurs qui attendent de savoir si leur modification est sûre à fusionner.

Plus tard, j’ai travaillé sur la formation de modèles sur notre propre base de code, ce qui a rendu l’asymétrie évidente. Un modèle peut produire rapidement une implémentation plausible. Montrer que cette implémentation s’intègre à un système de production en direct, respecte les conventions réellement utilisées par l’équipe et ne casse rien à deux services de distance prend beaucoup plus de temps, et la plupart de ce travail retombe sur les personnes. Gitar est né de cela, et cela s’aligne avec ce que Sonar fait du côté de l’analyse depuis plus de dix‑sept ans.

Vous avez soutenu que la revue de code IA doit compléter l’analyse déterministe plutôt que la remplacer. Quels types de problèmes sont le mieux identifiés par une analyse répétable et basée sur des règles, et où l’IA peut‑elle offrir des capacités que les techniques traditionnelles ne peuvent pas ?

L’analyse basée sur des règles est l’outil adéquat lorsque la propriété est décidable à partir du code lui‑même. Entrée contaminée atteignant un sink, déréférencement nul sur un chemin manqué, identifiant codé en dur, dépendance avec une CVE connue, import qui franchit une couche interdite. Vous obtenez la même réponse à chaque exécution et vous pouvez indiquer la raison du déclenchement, ce qui explique pourquoi l’application de la règle appartient à ce niveau.

Ce que les règles ne couvrent pas, c’est l’intention. Aucun parseur ne vous dira qu’une chaîne destinée à l’utilisateur sera ambiguë pour le traducteur, ou qu’une modification prétend fermer un ticket tout en implémentant seulement la moitié de ce que le ticket demandait, ou qu’une nouvelle boucle de retry entre en conflit avec la façon dont le reste du service gère la pression arrière. Un modèle qui lit le diff avec le ticket lié et le contexte complet du code soulèvera ces points, et ils devraient apparaître comme des constats qu’une personne vérifie plutôt que comme des verdicts.

Les systèmes d’IA peuvent évaluer la logique métier, l’intention du développeur et les compromis architecturaux, mais leurs conclusions sont probabilistes. Comment les équipes de développement peuvent‑elles tirer parti de ce raisonnement contextuel sans considérer la sortie d’un relecteur IA comme intrinsèquement correcte ?

La revue IA gagne sa place sur les problèmes que les contrôles conventionnels manquent : erreurs de logique, comportements qui ne correspondent pas à l’intention déclarée, modification qui semble correcte isolément mais qui est erronée pour ce système particulier. Ces conclusions sont probabilistes, elles doivent donc être intégrées comme entrée à une décision plutôt que d’être la décision elle‑même. Les équipes maintiennent cette frontière en conservant les contrôles déterministes avant la fusion, c’est‑à‑dire les tests automatisés, la validation CI, le scan de sécurité, les vérifications de politique, et un humain responsable du changement. L’IA peut proposer des correctifs, ou les appliquer dans les garde‑fous définis par l’équipe, tant que ces changements passent les mêmes vérifications que tout code rédigé par une personne et ne bénéficient d’aucun raccourci du fait d’être générés par une machine.

Nous appliquons la même frontière dans notre propre implémentation. Le modèle propose des constats, et le verdict de revue est calculé en code à partir de l’état de ces constats. La résolution fonctionne de la même façon. Lorsque le code à l’origine d’un constat disparaît du diff, il s’agit d’une vérification déterministe du diff analysé, et le modèle n’est pas autorisé à « dé‑résoudre » ce qui a déjà été corrigé.

La version générale consiste à confier à la couche probabiliste les tâches où l’erreur est récupérable, à garder la machine d’état déterministe, et à laisser la responsabilité à l’équipe. Ce qui inspire la confiance, c’est la preuve que quelqu’un peut inspecter et contrôler un comportement qui se reproduit de façon identique à chaque exécution.

Sonar combine des revues de pull‑request contextuelles avec une analyse déterministe et des portes de qualité. À quoi ressemble un processus de vérification multicouche efficace, et comment les différentes couches doivent‑elles interagir sans dupliquer le travail ni submerger les développeurs de constats ?

L’analyse déterministe et les portes de qualité portent les exigences non négociables, et ce sont elles qui bloquent une fusion. La revue contextuelle prend les jugements sur le fait qu’une modification fait ce qu’elle prétend, qu’elle s’intègre au code existant, et si le risque associé mérite l’attention d’une personne.

Un mur de constats est ignoré à peu près au même taux qu’une absence totale de constats. Nous dédupliquons entre les relecteurs avant que quoi que ce soit n’atteigne l’auteur, nous écartons les candidats que nous ne pouvons pas vérifier et nous nous concentrons sur les constats à fort signal. Du côté des règles, un prédicat décide si une règle s’applique au diff actuel avant que le modèle ne s’exécute, ainsi la plupart des règles ne coûtent rien sur la majorité des changements. Tout cela apparaît dans la pull‑request que le développeur a déjà ouverte.

À mesure que les agents de codage produisent davantage de code et de pull‑requests, la revue et la vérification du logiciel pourraient‑elles devenir le nouveau goulot d’étranglement ? Quelles parties du processus de revue devraient être automatisées, et quelles décisions devraient rester entre les mains d’ingénieurs expérimentés ?

La revue et la vérification sont déjà le goulot d’étranglement. En fait, notre enquête développeur State of Code 2026 a révélé que les équipes passent environ un quart de la semaine de travail à vérifier et corriger les sorties d’IA. De ce fait, il n’est pas surprenant que seulement 48 % des développeurs vérifient toujours le code généré par l’IA avant de le valider, bien que la majorité (96 %) n’aient pas pleinement confiance en sa justesse fonctionnelle.

Le travail qui vaut la peine d’être automatisé est mécanique et désagréable : isoler la cause racine d’un échec CI afin que personne ne doive lire quatre mille lignes de logs, décider si un constat reste applicable après un rebase, reproduire un échec, écrire le correctif évident. Les ingénieurs doivent conserver l’intention, la conception et le jugement sur la quantité de preuves suffisantes pour une modification donnée. Quand un ingénieur senior passe une soirée à lire des logs pour déterminer lequel des neuf échecs importe, il s’agit de triage plutôt que de jugement, et c’est exactement le type de travail que nous devrions leur ôter.

Les systèmes de revue de code IA peuvent identifier des problèmes, proposer des correctifs et valider ces changements dans le pipeline d’intégration continue. Comment empêcher un système de remédiation autonome d’introduire des régressions ou d’optimiser trop étroitement pour un build réussi au détriment de la qualité globale du logiciel ?

Le principal est de refuser de prendre le vert comme critère d’acceptation, car un build qui passe indique seulement que les tests existants n’ont pas échoué.

La plupart des contraintes que nous imposons à notre propre remédiation concernent le périmètre. Gitar corrige les CI qui ont échoué, et il vérifie que le commit précédant son propre push était vert avant de revendiquer la responsabilité de quoi que ce soit. Il s’arrête après deux commits de suivi plutôt que de s’obstiner sur un build rouge. Quand l’échec n’a rien à voir avec la modification, un test flaky ou un incident d’infrastructure, cela suit le chemin de la relance plutôt que celui du correctif, parce que « faire cesser l’échec du test » est l’objectif que l’on veut le moins voir poursuivi par un agent capable.

Ensuite, la modification doit passer une couche que Gitar ne contrôle pas. SonarQube évalue le résultat selon ses propres critères, la porte de qualité est ce dont dépend la fusion, et l’équipe possède cette politique. Nous vérifions également la modification par rapport au ticket qu’elle prétend implémenter, en séparant l’extraction des exigences du jugement de complétion, de sorte qu’une exigence qui aurait discrètement quitté le ticket ne puisse revenir comme implémentée.

Une revue de code IA efficace nécessite de comprendre les conventions, dépendances, architecture et objectif d’une modification dans un dépôt. Quel contexte un relecteur IA doit‑il disposer pour prendre des décisions utiles, et comment les organisations peuvent‑elles garder ce contexte à jour à mesure que leurs systèmes évoluent ?

Il faut suffisamment de contexte pour raisonner comme un relecteur expérimenté, pas seulement assez pour lire le diff. Cela inclut le but de la modification, les chemins de code pertinents et les informations de type, les dépendances, le comportement des tests, les conventions du dépôt et les limites architecturales que l’équipe attend que la modification respecte.

Le contexte doit également vivre avec le code. Conservez les règles et les consignes de revue versionnées dans le dépôt, mettez‑les à jour lorsque les services ou les conventions changent, et clarifiez la responsabilité des décisions architecturales et de politique. Sinon, un relecteur IA peut proposer une suggestion plausible qui entre en conflit avec le fonctionnement réel du système plus large.

L’analyse déterministe produit des résultats cohérents et auditables, tandis que la revue basée sur les grands modèles de langage peut varier d’une exécution à l’autre. Comment les entreprises doivent‑elles documenter, reproduire et gouverner les constats générés par l’IA dans des environnements réglementés ou sensibles à la sécurité ?

La traçabilité doit montrer la modification revue, le constat IA, la décision prise et les preuves indépendantes utilisées pour valider le résultat. Les équipes peuvent exploiter l’IA pour accélérer la revue et la remédiation, tout en maintenant les décisions d’application et d’approbation ancrées dans des politiques définies et la responsabilité humaine.

Quels indicateurs les responsables techniques devraient‑ils utiliser pour déterminer si la revue de code IA améliore réellement le développement logiciel ? Doivent‑ils privilégier le temps de revue, les défauts qui échappent, les taux de faux positifs, les échecs d’intégration continue, la dette technique, la confiance des développeurs ou une autre mesure ?

Commencez par les résultats, pas par le nombre de commentaires produits par l’IA. Je mesurerais le temps entre la pull‑request et la fusion, le temps passé à diagnostiquer les échecs CI, le taux de correctifs qui passent dès la première tentative de validation, et la fréquence à laquelle des problèmes passent aux étapes suivantes ou en production.

Ensuite, surveillez les signaux de qualité comme les taux de faux positifs et de rejets, les tickets rouverts, les régressions liées à des changements récemment fusionnés, et les retours des développeurs sur l’utilité des constats. Le bon mélange d’indicateurs varie selon l’équipe, mais la question reste constante : réduisons‑nous le retravail et le temps d’attente de revue sans baisser le niveau de sécurité du logiciel ?

En regardant vers l’avenir, pensez‑vous que le développement logiciel deviendra une boucle continue où les agents génèrent, reviennent, testent et réparent le code sous des garde‑fous déterministes ? Dans ce contexte, comment les responsabilités et les compétences requises des ingénieurs logiciels humains évolueront‑elles ?

Cette boucle existe déjà, et les équipes ont tendance à l’adopter dans un ordre fixe : détection d’abord, puis remédiation, puis approbation selon des conditions qu’elles consignent, puis fusion. Personne ne passe directement à la dernière étape, et la preuve qui les fait avancer provient de leur propre base de code plutôt que d’un benchmark. La fusion est l’étape que je trouve la plus intéressante, car la fréquence des conflits augmente avec le débit de commits, et le débit est ce que tout cela accroît.

Les compétences qui gagnent en valeur se situent autour de la boucle plutôt qu’à l’intérieur. Être précis sur le problème et ses contraintes compte davantage lorsqu’un agent prend votre description à la lettre. Il en va de même pour décider quelles preuves sont suffisantes pour laisser passer une modification, ce qui était auparavant une habitude tacite et qui doit maintenant être formalisé en politique que l’automatisation peut appliquer. Le reste relève de la conception de systèmes : délimiter ce que le travail automatisé peut toucher, disposer d’un mécanisme que l’agent ne contrôle pas pour vérifier le résultat, et garder la traçabilité lorsqu’une erreur survient. Les ingénieurs passeront moins de temps à produire l’implémentation et davantage à décider ce qui doit exister et ce qui constituera la preuve de son bon fonctionnement.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Sonar.