Prince Kohli, président et PDG de Sauce Labs – Série d’interviews

Prince Kohli, président et PDG de Sauce Labs, est un cadre technologique chevronné doté d’une vaste expérience couvrant l’intelligence artificielle, les logiciels d’entreprise, l’informatique en nuage, l’automatisation, les réseaux et la cybersécurité. Avant de rejoindre Sauce Labs en février 2025, il a passé plus de six ans en tant que Chief Technology Officer d’Automation Anywhere, où il a contribué à faire progresser les technologies d’automatisation pilotées par l’IA pour les grandes entreprises. Auparavant, Kohli a occupé le poste de Senior Vice President of Engineering chez ThoughtSpot et a exercé des fonctions de direction senior chez Ericsson, notamment la supervision d’organisations mondiales de R&D regroupant plus de 10 000 ingénieurs. Il a également passé près d’une décennie chez Citrix, dirigeant les initiatives de plateforme, de réseau cloud, d’ingénierie et d’opérations. Au début de sa carrière, il a cofondé la société de sécurité des applications Teros et a travaillé comme responsable technique chez SGI. Parallèlement à ses fonctions exécutives, Kohli a contribué à des initiatives de gouvernance technologique via le Ethical AI Governance Group et a précédemment participé au groupe de travail Safe Systems and Technologies du Forum économique mondial.

Sauce Labs est une société de qualité logicielle et de tests continus qui fournit aux entreprises une infrastructure et des outils pour tester des applications web et mobiles sur différents navigateurs, systèmes d’exploitation, environnements virtuels et appareils réels. Sa plateforme prend en charge des fonctionnalités telles que les tests automatisés et manuels, les tests visuels, la distribution d’applications mobiles, le reporting d’erreurs et la création et l’analyse de tests alimentées par l’IA, tout en s’intégrant aux flux de travail courants d’intégration et de livraison continues. Sauce Labs positionne de plus en plus sa technologie autour d’AURA, sa plateforme d’Assurance de Release Unifiée par l’IA, qui utilise des agents IA pour aider à générer, exécuter et analyser les tests tout en conservant la supervision humaine tout au long du processus de mise en production. L’entreprise affirme que son infrastructure a pris en charge plus de 8,7 milliards d’exécutions de tests et plus de 300 000 utilisateurs d’entreprise, s’appuyant sur près de deux décennies de données de tests multiplateformes.

Avant de rejoindre Sauce Labs, vous avez dirigé l’automatisation pilotée par l’IA chez Automation Anywhere et géré d’importantes organisations cloud et d’ingénierie dans des entreprises telles qu’Ericsson et Citrix. Comment ces expériences ont‑elles façonné votre vision du problème de la qualité logicielle, et qu’est‑ce qui vous a convaincu de faire de l’assurance de release native IA une priorité centrale chez Sauce Labs ?

Chez Ericsson et Citrix, j’ai constaté à quelle vitesse un défaut logiciel peut se propager et affecter l’infrastructure mondiale, engendrant d’importantes répercussions sur la sécurité, les opérations client, la confiance et les revenus. Automation Anywhere m’a montré comment l’IA modifie la vitesse et la structure du travail, et il est devenu évident que les tests devaient être repensés pour le rythme du logiciel généré par l’IA. Sauce Labs a été pionnier de l’automatisation des tests, ainsi l’assurance de release native IA est le prochain problème majeur que nous sommes conçus pour résoudre.

Les recherches de Sauce Labs ont révélé que 80 % des organisations ont attribué un incident de production, une panne ou un défaut impactant les clients à du code généré par l’IA. Cela indique‑t‑il principalement des faiblesses du code produit par l’IA, ou bien que les entreprises adoptent des outils de codage IA sans mettre à jour leurs processus de test et de gouvernance ?

Le chiffre de 80 % indique un problème qui touche l’ensemble du système de livraison logicielle. L’industrie de l’IA a attiré plus d’un trillion de dollars de capitaux privés, dont une grande partie repose sur l’idée que l’IA rend les entreprises beaucoup plus productives. Cependant, générer davantage de code ne crée de la valeur que si les entreprises peuvent être sûres de sa qualité et de sa sécurité avant de le mettre en production.

Le code généré par l’IA peut introduire des bugs subtils et des problèmes de sécurité, et les entreprises sont contraintes de faire passer ce code à travers des processus de test et de gouvernance déjà en difficulté pour suivre le rythme. Cela crée un problème d’exécution d’un trillion de dollars : l’IA peut accélérer la création de logiciels, mais sans une assurance de release modernisée, elle accélère tout aussi facilement les défauts. Chaque bug finira par être rencontré, il faut donc que les entreprises s’assurent de le détecter avant le client ou l’attaquant.

Le rapport indique que les développeurs produisent 741 % de code supplémentaire tandis que la vitesse de mise en production n’a augmenté que de moins de 20 %. Qu’est‑ce qui empêche les systèmes de validation de suivre le rythme, et où le goulot d’étranglement le plus important apparaît‑il généralement dans le cycle de vie du développement logiciel ?

La génération de code a largement dépassé la création, la maintenance et l’analyse des tests. Les plus gros goulots d’étranglement apparaissent généralement après l’écriture du code, lorsqu’il faut le vérifier dans le contexte du parcours utilisateur. Cela peut souvent être très complexe, parfois plus complexe que le code lui‑même, car il faut prendre en compte des chemins de bout en bout qui traversent fonctions et objets du code, où de légères modifications sémantiques à un endroit entraînent d’importants effets en aval. Rédiger ces tests de manière à ce qu’ils saisissent correctement et complètement l’intention de l’application a longtemps été presque impossible, en plus de nécessiter une quantité très importante de travail manuel et de maintenance. De plus, après l’exécution des tests et l’apparition d’un échec, les équipes doivent comprendre et diagnostiquer le problème, y compris décider si l’échec provient du produit ou d’un test obsolète. Ce travail dépend encore fortement de la revue manuelle et du contexte d’ingénierie.

Plus de la moitié des entreprises interrogées ont reconnu publier sciemment des logiciels contenant des défauts critiques, tandis que 66 % ont indiqué avoir compromis la qualité ou les normes de test pour respecter un délai. Pourquoi les organisations acceptent‑elles ce niveau de risque, et que faudrait‑il changer pour que la qualité logicielle devienne une priorité au niveau de l’entreprise plutôt qu’un simple point de contrôle technique final ?

Les organisations acceptent le risque parce que les objectifs de mise en production sont liés à des engagements immédiats envers les clients, les revenus et les produits, et les coûts des défauts apparaissent souvent plus tard dans plusieurs équipes. La qualité ne devient une priorité métier que lorsque les dirigeants mesurent les incidents en production, l’impact client, l’exposition à la sécurité, les coûts de retouche et les revenus différés en même temps que la vitesse de mise en production.

Sauce Labs positionne AURA comme une plateforme en boucle fermée qui crée, exécute et analyse les tests tout en apprenant de chaque mise en production. En quoi cela diffère‑t‑il techniquement et opérationnellement de la génération de tests assistée par l’IA, des scripts de test auto‑réparateurs ou d’autres outils d’automatisation déjà utilisés par les équipes d’ingénierie ?

La plupart des outils de test IA traitent une tâche spécifique, comme la génération d’un test ou la réparation d’un sélecteur défectueux. AURA relie l’ensemble du processus en comprenant l’intention de l’application, en créant et exécutant les tests, en analysant les échecs et en renvoyant le comportement en production aux équipes de développement. Elle peut gérer automatiquement de nombreux changements et faire intervenir une personne lorsque le sens ou le comportement attendu de l’application a évolué. De plus, les tests qu’elle génère sont stables, c’est‑à‑dire qu’ils n’ont pas besoin d’être modifiés lorsque des changements qui n’affectent pas la sémantique surviennent dans les applications, les navigateurs, les appareils, etc. Enfin, comme AURA intègre en elle-même un cloud d’exécution de tests, elle peut décharger l’ensemble du processus d’un développeur ou d’une équipe d’ingénierie qualité.

AURA est conçue pour vérifier le logiciel par rapport à « l’intention métier ». Comment cette intention est‑elle définie et traduite en exigences testables, qui est responsable de son approbation, et comment la plateforme gère‑t‑elle les exigences ambiguës, incomplètes ou sujettes à interprétation ?

L’intention métier provient des exigences produit, des critères d’acceptation, des règles métier, des parcours utilisateurs et de la façon dont les clients utilisent réellement l’application. Les responsables produit définissent le résultat attendu, et les équipes d’ingénierie et de qualité traduisent ce résultat en comportements que le système peut vérifier. Lorsque les exigences sont incomplètes ou ambiguës, AURA doit mettre en évidence l’incertitude et demander une approbation humaine avant de modifier le résultat attendu.

Sauce Labs rapporte que les entreprises utilisant AURA ont constaté 90 % d’incidents de production en moins, des cycles de mise en production 47 % plus rapides et une récupération de 38 % de la capacité d’ingénierie. Comment ces résultats ont‑ils été mesurés, sur quelles périodes de déploiement, et quelle validation indépendante a été utilisée pour distinguer l’impact d’AURA des autres changements organisationnels ou d’ingénierie ?

Dans le cadre des déploiements d’entreprise, nous avons mesuré les variations des incidents en production, de la vitesse des cycles de mise en production et de la capacité d’ingénierie après que les équipes aient mis en place AURA. Ces déploiements ont enregistré plus de 90 % d’incidents en production en moins, des cycles de mise en production 47 % plus rapides et 38 % de capacité d’ingénierie récupérée, les résultats ayant été validés de manière indépendante. Des clients tels que Walmart et Keller Williams ont également signalé des gains significatifs en fréquence de mise en production, couverture des tests et temps de cycle.

La recherche a constaté que 64 % des organisations ont augmenté leurs effectifs d’assurance qualité alors que les incidents continuaient d’augmenter. Pourquoi les entreprises ne peuvent‑elles pas combler le fossé de vérification simplement en recrutant davantage de testeurs, et comment pensez‑vous que les responsabilités des développeurs, des ingénieurs qualité et des équipes de fiabilité du site évolueront à mesure que les tests deviendront plus autonomes ?

L’IA peut augmenter le volume de code beaucoup plus rapidement qu’une entreprise ne peut augmenter ses effectifs de test, et l’ajout de personnel crée également davantage de transferts et de coordination. Les développeurs devront définir clairement l’intention, les ingénieurs qualité se concentreront davantage sur le risque, la couverture et la gouvernance, et les équipes de fiabilité du site renverront le comportement en production dans le processus de mise en production. Les agents peuvent gérer l’exécution et l’analyse répétitives à l’échelle requise par ce nouveau modèle de développement.

À mesure que les agents IA gagnent en responsabilité pour la rédaction, l’exécution et l’interprétation des tests, où les humains doivent‑ils conserver l’autorité décisionnelle ? Quels types d’incertitude, de risque de sécurité ou d’impact potentiel sur le client devraient automatiquement arrêter une mise en production ou déclencher une revue humaine ?

Les humains doivent conserver l’autorité finale sur les décisions de mise en production, notamment lorsque le jugement, l’impact client ou le risque métier sont en jeu. Les agents IA peuvent automatiser les tâches de test fastidieuses, répétitives et clairement définies, mais les humains doivent approuver les mises en production chaque fois que le code ou les résultats des tests ne peuvent pas être pleinement compris, expliqués ou reproduits. La revue doit également être obligatoire lorsque les exigences sont floues, que des vulnérabilités de sécurité sont possibles, que les composants tiers n’ont pas été suffisamment validés, ou que des échecs pourraient affecter les revenus, les données sensibles, l’expérience client ou les opérations critiques.

Dans ces situations, un comportement inexpliqué, des résultats de test incohérents ou une preuve insuffisante de la préparation à la mise en production devraient automatiquement arrêter la mise en production.

Nous avons observé chez certains de nos clients des cas où un test apparaissant « instable », réussissant de manière incohérente sans motif d’échec apparent, était souvent ignoré. Mais des processus bien gouvernés chez certains de ces clients ont exigé une diligence raisonnable et, grâce à notre plateforme, ils ont pu remonter l’échec à un défaut subtil mais critique lié au timing, qui aurait pu entraîner des impacts majeurs s’il avait été déployé, avec un coût très élevé.

Vous avez également travaillé avec le Ethical AI Governance Group et le groupe de travail Safe Systems and Technologies du Forum économique mondial. À mesure que le code généré par l’IA et les tests autonomes se connectent davantage, quelles normes de gouvernance les entreprises devront‑elles adopter pour s’assurer que la création de logiciels plus rapide n’introduise pas de nouveaux risques systémiques, de sécurité ou de responsabilité ?

Plus l’IA peut créer rapidement des logiciels, plus la couche de vérification et de gouvernance doit être robuste. Cette couche comporte de nombreuses composantes. Les entreprises doivent définir des limites claires sur ce que les agents peuvent décider de manière autonome, avec une revue humaine requise lorsqu’il existe une incertitude concernant l’intention métier, la sécurité, la conformité ou un changement sémantique significatif. Elles ont également besoin d’une traçabilité sur ce qu’un agent a modifié, pourquoi il l’a modifié et quelles preuves ont soutenu la décision de mise en production. En fin de compte, la gouvernance doit être mesurée par la qualité et la prévisibilité de ce qui atteint la production, comme le suivi précis de la fréquence à laquelle le code généré provoque des incidents dans les 90 jours suivant la mise en production, et non par la rapidité avec laquelle l’IA peut générer du code.

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