Sapan Pandya, ingénieur logiciel senior et membre senior de l’IEEE – Série d’entretiens

Sapan Pandya est ingénieur logiciel senior et membre senior de l’IEEE. Il est basé dans le New Jersey et possède plus de dix ans d’expérience des systèmes de transactions distribués résilients. Ses travaux portent sur l’intégrité des transactions, l’intégration entre les logiciels et les appareils physiques, le dépannage en production et la validation des déploiements dans des environnements réglementés. Il est titulaire d’un master en informatique du Stevens Institute of Technology et contribue à l’évaluation de travaux universitaires ainsi qu’à la recherche technique.

Les recherches de Pandya portent sur la cybersécurité des bornes interactives, l’IA en périphérie et l’ingénierie de la fiabilité assistée par l’IA. Son expérience en production nourrit son intérêt pour les éléments probants, les résultats des transactions et la responsabilité opérationnelle. Dans cet entretien, il aborde l’idempotence, les divergences entre les enregistrements de transactions, l’incertitude dans les systèmes de reprise et les contrôles nécessaires avant que des agents d’IA puissent intervenir sur des infrastructures critiques. Il distingue l’expérience pratique en ingénierie de la recherche menée à partir d’analyses documentaires et de tests contrôlés ou synthétiques.

Votre carrière est axée sur la fiabilité logicielle et les systèmes de transactions distribués. Comment cette expérience a-t-elle façonné votre conception de la fiabilité, et quels défis ont influencé votre point de vue sur l’utilisation de l’IA pour gérer des systèmes complexes ?

Mon point de vue a évolué : au lieu de me demander si un composant fonctionne, je me demande si la transaction du client est terminée et si l’on peut en rendre compte.

Au début de ma carrière, je m’intéressais surtout au comportement des applications : valider les données saisies, traiter les réponses et veiller à ce que l’interface respecte le processus prévu. À mesure que mes responsabilités se sont étendues à l’intégration des systèmes, au dépannage en production et à la validation des déploiements, j’ai dû voir au-delà des composants pris individuellement.

Un service peut avoir terminé son travail alors qu’un autre attend encore une confirmation. Un logiciel peut consigner la réussite d’une opération alors qu’un appareil physique ne parvient pas à fournir le résultat attendu. Le fait que chaque composant réussisse les tests ne suffit pas, à lui seul, à garantir que l’interaction dans son ensemble se déroulera correctement.

Cette expérience m’a particulièrement sensibilisé aux interfaces entre les systèmes. Que sait chaque composant ? Quelles hypothèses fait-il ? Que se passe-t-il lorsque ces hypothèses cessent d’être valables ?

Elle influence également ma façon d’envisager l’IA. Aider les ingénieurs à réunir des éléments probants, à repérer des tendances et à examiner les défaillances plus rapidement présente un réel intérêt. Mais une explication de ce qui s’est probablement passé n’équivaut pas à un compte rendu vérifié de ce qui s’est réellement passé.

Je souhaite que l’IA réduise les efforts nécessaires à l’examen d’un problème sans abaisser le niveau de preuve requis pour le résoudre.

Vous avez souligné qu’un code techniquement correct ne garantit pas toujours que les transactions aboutissent correctement. Pouvez-vous nous donner un exemple concret où une transaction semble avoir échoué à cause d’un délai d’attente dépassé, alors qu’elle a en réalité été menée à bien ? Que peut-il se passer si le système relance automatiquement l’opération, et comment les ingénieurs devraient-ils éviter les transactions en double ?

Prenons l’exemple hypothétique d’un paiement de 50 $. L’application envoie une requête, le service de paiement l’enregistre avec succès, mais la réponse se perd avant de parvenir à l’application.

Le client voit un délai d’attente dépassé alors que le paiement a déjà été effectué. Si l’application envoie une nouvelle requête de paiement, le client risque d’être débité une seconde fois.

Un délai d’attente dépassé signifie que la réponse n’est pas arrivée à temps. Cela ne permet pas de savoir si la transaction sous-jacente a abouti.

L’idempotence est une mesure de protection courante : elle permet de répéter une même requête logique sans produire un nouvel effet financier. L’application conserve le même identifiant d’opération lors des nouvelles tentatives, et le service destinataire le reconnaît comme la requête d’origine plutôt que comme un nouvel achat.

L’essentiel ne consiste pas simplement à joindre un identifiant. Le service doit faire respecter cette identité et conserver suffisamment d’informations pour distinguer une opération terminée d’une opération toujours en cours. Un identifiant ne peut pas protéger une action en aval qui ne le prend pas en compte.

Lorsque l’issue demeure incertaine, le processus de reprise devrait vérifier la transaction existante et rapprocher les enregistrements concernés, au lieu d’en créer immédiatement une nouvelle.

Je limiterais également le nombre de nouvelles tentatives et définirais la marche à suivre lorsque la reprise automatique ne permet pas d’établir l’issue de l’opération. Le client doit voir clairement que l’opération est en attente et disposer d’une solution pour la régler, plutôt que subir des débits répétés ou rester bloqué sur un écran de traitement sans fin.

Dans les systèmes distribués, une base de données, un service dorsal et une borne physique peuvent communiquer des informations contradictoires au sujet d’une même transaction. Avez-vous rencontré ce type d’incohérence en production ? Comment a-t-elle été examinée et résolue ? Quel rôle, le cas échéant, l’IA pourrait-elle jouer pour rapprocher ces enregistrements contradictoires ?

Oui, l’examen des incohérences dans l’état des transactions a fait partie de mon travail en production. Pour expliquer le raisonnement sans évoquer un incident survenu au travail, je vais prendre un exemple hypothétique.

Prenons l’exemple d’une caisse libre-service ordinaire. Le service de paiement enregistre un achat comme réussi, l’imprimante indique qu’elle a accepté la tâche d’impression du reçu, puis l’écran affiche une erreur. Ces observations peuvent correspondre à différentes étapes de l’interaction sans pour autant prouver que l’achat a entièrement échoué.

Je commencerais par reconstituer la séquence à partir de l’identifiant de transaction et des journaux pertinents des services et des appareils. J’établirais ensuite ce que prouve chaque observation. Le fait qu’une imprimante accepte une tâche ne prouve pas nécessairement que le client a reçu le reçu. De même, la réception d’une demande ne prouve pas nécessairement que ses effets financiers ont été comptabilisés.

La résolution dépend de l’étape qui a échoué. Il pourrait être inapproprié de répéter toute la transaction si seule l’étape de sortie nécessite une intervention. Si les éléments disponibles ne permettent pas d’établir ce qui s’est passé, l’opération concernée devrait rester sous contrôle pendant qu’une personne mène l’enquête.

La correction durable doit aussi s’attaquer à la cause de cette incohérence, plutôt que de simplement réparer un enregistrement.

L’IA pourrait aider à mettre les événements en corrélation et à repérer les informations manquantes. Je lui demanderais de présenter plusieurs explications possibles, ainsi que les éléments qui étayent chacune d’elles. Elle devrait aider à circonscrire l’enquête, et non trancher entre des enregistrements contradictoires en privilégiant l’explication qui semble la plus convaincante.

À mesure que les agents d’IA passent du diagnostic des incidents en production à la recommandation ou à l’exécution de mesures de rétablissement, quelles garanties devraient être en place avant qu’un système d’IA puisse relancer, annuler ou modifier une transaction ? Comment des contrôles déterministes, tels que les clés d’idempotence, les journaux de transactions et les mécanismes de rapprochement, peuvent-ils empêcher l’IA de provoquer d’autres défaillances ?

Je distinguerais la proposition d’une action de son autorisation et de son exécution.

Un agent d’IA pourrait recommander une nouvelle tentative, mais un contrôle distinct devrait déterminer si elle est autorisée. Il devrait vérifier l’état actuel de la transaction, l’identité de l’opération, les autorisations de l’agent et les conditions dans lesquelles cette action peut être exécutée sans risque.

Cette vérification doit avoir lieu au moment de l’exécution de l’action, et pas seulement lorsque le modèle examine l’incident pour la première fois. Entre-temps, un autre processus pourrait avoir mené la transaction à son terme.

Les outils mis à la disposition de l’agent devraient également être limités. L’autorisation de consulter l’état d’une transaction ne donne pas le droit d’annuler un paiement ou de modifier un enregistrement financier. L’agent ne devrait pas pouvoir étendre ses propres pouvoirs au motif que la solution qu’il privilégie exige un accès plus étendu.

L’idempotence limite les effets en double. Les journaux conservent l’historique nécessaire à l’enquête. Le rapprochement permet de vérifier la concordance entre les enregistrements pertinents. Aucun de ces mécanismes, à lui seul, ne permet d’établir si une action proposée est appropriée.

J’enregistrerais également les éléments pris en compte, la recommandation, la décision d’autorisation et le résultat obtenu. Il serait ainsi possible d’examiner l’intervention a posteriori.

Ces contrôles devraient être imposés par des logiciels vérifiables qui ne dépendent pas du modèle. Dire à un agent de faire preuve de prudence constitue une consigne utile, mais ne remplace pas un mécanisme d’autorisation.

Imaginons qu’un système de surveillance fondé sur l’IA détecte une défaillance apparente d’une transaction et recommande de l’annuler automatiquement. Si la transaction a en réalité abouti, mais que la confirmation a tardé, cette intervention pourrait créer un nouveau problème. Comment les équipes d’ingénierie devraient-elles concevoir des systèmes de rétablissement pilotés par l’IA afin qu’ils reconnaissent l’incertitude et évitent de prendre des mesures correctives à partir d’informations incomplètes ?

Le système doit prévoir un véritable état « résultat inconnu ». À défaut, il risque de transformer un manque d’information en une conclusion erronée d’échec.

Une confirmation tardive justifie une enquête, mais pas automatiquement l’annulation d’une transaction. Une annulation constitue une autre opération financière, qui entraîne ses propres conséquences. Elle doit reposer sur un motif établi de manière indépendante et être dûment autorisée.

Je distinguerais deux volets dans la réponse. Le volet d’enquête peut consister à consulter l’état de la transaction, à recueillir les événements manquants, à comparer les enregistrements et à avertir l’équipe responsable. Le volet des opérations financières reste bloqué tant que ses conditions ne sont pas remplies.

Cela empêche qu’un score de confiance de l’IA se substitue aux éléments de preuve relatifs à la transaction. Un modèle peut être très sûr d’une explication élaborée à partir d’informations incomplètes.

Il faut également définir un seuil à partir duquel le dossier est transmis. Laisser une transaction en attente indéfiniment n’est pas une issue satisfaisante pour le client. Une personne devrait être chargée du dossier non résolu et disposer d’un contexte suffisant pour déterminer la prochaine étape à suivre sans risque.

Le processus de rétablissement devrait donc pouvoir dire à la fois : « Je ne peux pas encore justifier la modification de cette transaction » et « Voici ce qu’il faut faire pour la résoudre ».

Reconnaître l’incertitude n’est utile que si le système dispose d’un moyen concret de la gérer.

L’une des principales questions que soulève l’IA autonome consiste à déterminer dans quelles situations l’approbation d’un être humain reste indispensable. Quelles mesures de reprise en production, selon vous, l’IA devrait-elle être autorisée à exécuter de façon autonome, et lesquelles devraient toujours nécessiter une autorisation humaine ? Comment les organisations devraient-elles définir ces limites lorsque des transactions financières, la conformité réglementaire ou la confiance des clients sont en jeu ?

Je fixerais la limite en fonction des conséquences d’une erreur, plutôt qu’en fonction du fait qu’une action soit qualifiée d’« IA ».

Une investigation en lecture seule constitue un bon point de départ, à condition que l’agent n’ait accès qu’aux informations autorisées. Il peut recueillir des données de diagnostic, regrouper les alertes connexes et préparer un résumé de l’incident sans être autorisé à modifier la transaction sous-jacente.

Certaines procédures de reprise prédéfinies peuvent également se prêter à l’automatisation lorsque leurs conditions sont vérifiées indépendamment et que leurs effets sont limités.

J’exigerais une autorisation humaine lorsqu’une intervention proposée sort du cadre d’une procédure approuvée, lorsque les enregistrements se contredisent et que l’issue financière reste indéterminée, ou lorsque l’action modifierait les contrôles de sécurité ou les propres autorisations de l’agent. Ce sont des décisions qu’un agent ne devrait pas pouvoir autoriser lui-même.

Cela ne signifie pas qu’une personne doive approuver chaque opération financière courante. Un traitement fondé sur des règles établies n’est pas la même chose que de laisser un modèle inventer une correction en pleine gestion d’incident.

L’examen humain doit aussi être réel. Un écran d’approbation devrait présenter les éléments de preuve à l’appui, les incertitudes qui subsistent, l’effet attendu et les solutions de rechange possibles. Demander à quelqu’un d’approuver un paragraphe formulé avec assurance, sans lui fournir ce contexte, n’offre guère de protection supplémentaire.

Ces limites devraient être définies d’un commun accord avant le déploiement. Une panne n’est pas le bon moment pour décider du degré d’autorité à accorder à un système automatisé.

Vous avez beaucoup travaillé sur des systèmes dorsaux tolérants aux pannes, des outils d’observabilité et des intégrations entre services logiciels et matériel physique. De quelles données de télémétrie et de quels éléments de preuve issus de la production un agent d’IA aurait-il besoin pour diagnostiquer un incident de manière fiable ? Comment les équipes d’ingénierie peuvent-elles distinguer les recommandations utiles générées par l’IA des conclusions plausibles, mais erronées, susceptibles d’aggraver une panne ?

Je commencerais par réunir des éléments de preuve qui permettent de suivre l’opération du client dans les différents systèmes concernés : identifiants de transaction, événements de service, changements d’état persistants, réponses des appareils et défaillances de communication.

Les versions logicielles et les changements de configuration comptent également. Une défaillance qui survient après une mise en production constitue une piste utile pour l’enquête, mais la seule proximité dans le temps ne prouve pas un lien de causalité.

L’agent doit aussi comprendre les limites des éléments de preuve. Les journaux peuvent être incomplets, les enregistrements arriver en retard et les horloges ne pas être synchronisées. L’absence d’un accusé de réception ne prouve pas qu’aucune opération n’a eu lieu.

Un diagnostic utile devrait distinguer les observations des interprétations. « Le client a enregistré un délai d’attente dépassé » est une observation. « Le système dorsal était indisponible » est une explication qui nécessite des éléments supplémentaires.

Je m’attendrais à ce qu’une recommandation indique les enregistrements sur lesquels elle s’appuie, explique ce qui demeure inconnu et précise quelle vérification supplémentaire permettrait de confirmer ou d’infirmer sa conclusion.

Les ingénieurs devraient ensuite vérifier les recommandations susceptibles d’avoir des conséquences en consultant les enregistrements d’origine, plutôt que de se fier uniquement au résumé de l’agent. C’est particulièrement important lorsqu’un résumé condense un historique d’événements long ou contradictoire.

La norme que j’appliquerais est simple : un autre ingénieur peut-il examiner les éléments de preuve et parvenir à une conclusion défendable ? Si l’explication ne résiste pas à cette vérification, elle n’est pas prête à justifier une modification en production.

Dans vos recherches publiées sur la résilience face aux rançongiciels des bornes de loterie et de paris, vous avez évalué un cadre de sécurité assisté par l’IA dans un environnement synthétique simulant 500 bornes. Quels ont été les principaux résultats, et quelles limites les lecteurs devraient-ils garder à l’esprit pour les interpréter ? Quelles validations supplémentaires seraient nécessaires avant d’appliquer l’architecture proposée à un environnement de production réel ?

Je voulais étudier la résilience au-delà de la détection : comment un environnement de terminaux pouvait limiter une attaque, la détecter et rétablir le système tout en préservant les traces de ce qui s’était passé.

Le Resilient Security Framework qui en a résulté associait des mesures préventives, la détection des anomalies assistée par l’IA et des mécanismes définis de réponse et de reprise. Le volet consacré à l’IA portait sur la détection des comportements suspects. Il ne s’agissait pas d’une expérience visant à autoriser un agent fondé sur un modèle de langage à modifier de façon autonome des transactions financières.

L’évaluation s’est déroulée dans un environnement synthétique représentant 500 bornes sur une simulation de 72 heures, avec des émulations comportementales d’attaques par rançongiciel, et non lors d’un déploiement sur 500 terminaux physiques.

Par rapport à la référence de l’étude, fondée uniquement sur un antivirus, le temps moyen de détection est passé de 52 à 31 minutes et le temps moyen de reprise, de 120 à 56 minutes.

Ce sont les résultats obtenus avec le cadre combiné dans les conditions expérimentales. Ils ne doivent pas être attribués à la seule IA ni considérés comme des garanties de performance en conditions réelles. Un constat intéressant est qu’une détection plus précoce n’a pas, à elle seule, permis d’obtenir la même amélioration du rétablissement. La conception des mécanismes de confinement et de rétablissement comptait également.

Les limites sont importantes. Les charges de travail simulées, les conditions réseau, les comportements des attaques et les défenses de référence ne représentent pas tous les environnements opérationnels. Les différents appareils et applications nécessiteraient de nouvelles validations.

Avant toute utilisation en production, je souhaiterais des tests sur du matériel représentatif, une évaluation de sécurité indépendante, des évaluations de plus longue durée ainsi qu’une mesure rigoureuse des fausses alertes et de la surcharge de traitement.

Je testerais également le processus de rétablissement au regard de l’activité légitime des transactions. Restaurer une image logicielle fonctionnelle ne suffit pas si le processus entraîne la perte des informations nécessaires à la comptabilisation des transactions effectuées.

L’étude constitue un point de départ pour des tests supplémentaires. Démontrer un comportement sûr dans un environnement opérationnel réel est une étape distincte.

Votre point de vue conjugue des années d’ingénierie en production et des recherches universitaires sur la fiabilité logicielle et la sécurité pilotée par l’IA. Pourriez-vous distinguer les mécanismes de fiabilité que vous avez personnellement mis en œuvre ou exploités dans des systèmes en production réelle des approches que vous avez étudiées dans le cadre de recherches ou de tests simulés ? Selon vous, quelles capacités de rétablissement pilotées par l’IA sont déjà applicables en pratique aujourd’hui, et lesquelles restent largement expérimentales ?

Mon expérience en production comprend le développement et l’intégration de logiciels, la validation des transactions, le dépannage, les tests et la validation des versions.

Mes travaux de recherche publiés constituent un volet distinct de mon activité, et chaque étude doit être appréhendée au regard des méthodes et des limites qui lui sont propres.

L’article sur les rançongiciels évalue un cadre de sécurité proposé dans un environnement de test synthétique. Mon article sur l’IA en périphérie est une analyse de la littérature consacrée à l’intelligence embarquée et à ses applications possibles aux terminaux de transaction. Mon article publié dans IEEE FeedForward examine une architecture de fiabilité assistée par l’IA au moyen d’une simulation contrôlée, qui comprend la surveillance, la remontée des alertes et les mécanismes de repli.

Aucune de ces publications ne doit être interprétée comme la preuve que j’ai déployé un agent d’IA autonome habilité à intervenir sur des transactions financières en cours.

Pour les usages pratiques, je privilégierais une assistance que les ingénieurs peuvent examiner : des synthèses d’incidents liées aux enregistrements sources, des corrélations entre les alertes et des contrôles de diagnostic proposés. Leur utilité doit néanmoins être mesurée dans l’environnement où ces outils seront utilisés.

Le problème le plus complexe est celui du rétablissement sans cadre prédéfini, lorsqu’un modèle choisit et applique des changements dans des conditions imprévues. Cela exige un niveau de preuve bien supérieur à celui nécessaire pour une suggestion de diagnostic utile.

À mes yeux, mon expérience en production et mes recherches sont complémentaires : la première me permet de cerner les problèmes opérationnels, tandis que les secondes explorent des approches qui doivent encore faire leurs preuves par la validation.

À l’avenir, à mesure que les agents d’IA seront plus capables de détecter les anomalies, de diagnostiquer les défaillances et de coordonner le rétablissement dans des systèmes distribués, comment imaginez-vous l’évolution des relations entre les systèmes autonomes et les ingénieurs ? Quelles garanties techniques, quelles preuves opérationnelles et quels mécanismes de responsabilisation seraient nécessaires avant que les organisations puissent confier en toute confiance davantage de pouvoir à l’IA sur des infrastructures de production critiques ?

Je m’attends à ce que l’IA prenne en charge une part croissante du travail nécessaire pour reconstituer le déroulement d’un incident. Les ingénieurs pourraient commencer avec une chronologie utile, les composants touchés, les différentes explications possibles et les éléments manquants, au lieu de consacrer autant de temps à recueillir ces informations manuellement.

Les équipes disposeraient ainsi de plus de temps pour prendre les décisions qui nécessitent de comprendre les obligations du système et les conséquences de sa modification.

J’élargirais progressivement le pouvoir d’action. Un agent pourrait d’abord fonctionner en mode silencieux, en formulant des recommandations sans les appliquer. Les équipes pourraient comparer ces recommandations aux résultats examinés et tester le comportement de l’agent lorsque des informations sont manquantes, contradictoires ou obsolètes.

L’évaluation devrait porter sur les interventions erronées, les problèmes non détectés, les escalades inutiles et la capacité à corriger les erreurs de l’agent lui-même. Une recommandation rapide n’a aucune valeur si elle oriente l’équipe d’intervention dans la mauvaise direction.

L’octroi de pouvoirs plus étendus devrait également rester conditionnel. Une mise à jour du modèle ou une modification majeure du système peut invalider les tests antérieurs. Les équipes doivent pouvoir réduire ou retirer les autorisations de l’agent si son comportement ne répond plus aux exigences.

L’amélioration de l’automatisation ne supprime pas la responsabilité humaine. Quelqu’un doit être responsable des règles de fonctionnement, des preuves exigées avant toute modification et du processus d’enquête sur les défaillances.

Je pense que les ingénieurs consacreront moins de temps à recueillir des informations et davantage à définir, tester et maintenir les conditions qui justifient une intervention automatisée.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent suivre ses travaux sur la fiabilité des transactions distribuées et la récupération responsable assistée par l’IA peuvent entrer en contact avec Sapan Pandya.