Le bug à 89 millions de dollars : ce qu'Apple et Goldman Sachs ont raté sur l'IA dans la finance

J'étais assis dans mon bureau à domicile, un mardi soir en octobre dernier, quand le communiqué de presse du CFPB est apparu dans mon fil d'actualité. Apple et Goldman Sachs, condamnés à payer plus de 89 millions de dollars pour des défaillances systémiques dans leur traitement des contestations liées à l'Apple Card. J'ai lu l'ordonnance de consentement deux fois. Puis je l'ai lue une troisième fois, parce que je n'arrivais pas à croire ce que je voyais.

La défaillance centrale n'était pas une ingénierie financière exotique ayant mal tourné. Ce n'était pas un algorithme incontrôlé prenant des décisions de crédit discriminatoires. C'était un bouton. Un formulaire secondaire dans l'application Apple Wallet qui, lorsqu'il restait incomplet, faisait disparaître les contestations de facturation des consommateurs dans un vide numérique. Des dizaines de milliers de personnes ont signalé des débits non autorisés, et le système les a tout simplement... avalés. Aucune enquête. Aucun accusé de réception. Aucune résolution. Les consommateurs se sont retrouvés à payer la facture.

Je construis des systèmes d'IA pour gagner ma vie. Mon entreprise, Veriprajna, se concentre sur ce que nous appelons la deep AI — des architectures neuro-symboliques qui combinent la flexibilité des grands modèles de langage avec la rigueur mathématique de la vérification formelle. Quand j'ai lu cette ordonnance de consentement, je ne me suis pas senti conforté. Je me suis senti mal. Parce que tout ce qui a mal tourné avec l'Apple Card était évitable. Pas avec de meilleurs tests. Pas avec plus d'ingénieurs. Avec une façon fondamentalement différente de penser la manière dont les systèmes d'IA devraient être construits pour les secteurs réglementés.

Que s'est-il réellement passé avec votre contestation Apple Card ?

Laissez-moi vous détailler cette défaillance, car les détails comptent davantage que le chiffre qui fait les gros titres.

Apple et Goldman Sachs ont signé leur accord de partenariat en 2017. Apple posséderait l'expérience client — l'interface Wallet épurée, le système de messagerie, tout le front-end. Goldman Sachs serait la banque derrière le rideau, octroyant le crédit, traitant les transactions et enquêtant sur les contestations lorsque les choses tournaient mal.

En juin 2020, Apple a déployé une mise à jour du parcours « Signaler un problème ». Avant la mise à jour, vous touchiez une transaction suspecte, vous appuyiez sur « Signaler un problème » et vous étiez redirigé vers une conversation Messages avec Goldman Sachs. Simple. Après la mise à jour, Apple a ajouté un formulaire secondaire — une étape supplémentaire que les consommateurs étaient censés remplir après leur message initial.

Voici où tout a cassé : lorsque des personnes soumettaient leur contestation via Messages mais ne terminaient pas le formulaire secondaire, le système considérait la contestation comme incomplète. Il ne transmettait jamais la plainte à Goldman Sachs. D'un point de vue réglementaire, beaucoup de ces messages constituaient des avis d'erreur de facturation valides au sens du Truth in Lending Act. Légalement, ils auraient dû déclencher une enquête dans des délais précis. Au lieu de cela, ils ont disparu.

Des dizaines de milliers de contestations de consommateurs juridiquement valides ont été englouties par une machine à états que personne n'avait formellement vérifiée.

Je me souviens d'avoir lu ce détail et d'avoir pensé à toutes les conversations que j'ai eues avec des dirigeants de services financiers qui m'affirment que leurs systèmes sont « éprouvés au combat ». Éprouvés contre quoi ? Contre le scénario précis où un changement d'interface introduit un état mort dans un flux distribué ? Ce n'est pas le genre de chose que l'on détecte avec des tests unitaires et des sprints de QA.

La clause à 25 millions de dollars qui a tout fait dérailler

Il y a un détail enfoui dans l'ordonnance de consentement sur lequel je reviens sans cesse. Le contrat d'Apple avec Goldman Sachs prévoyait une clause de 25 millions de dollars de dommages-intérêts forfaitaires pour chaque retard de 90 jours causé par Goldman dans le lancement de l'Apple Card.

Vingt-cinq millions de dollars. Par trimestre. Pour être en retard.

J'ai été dans des salles où la pression commerciale déforme les décisions d'ingénierie. J'ai vu des équipes livrer des choses qu'elles savaient ne pas être prêtes parce que le coût du retard paraissait plus concret que le coût de l'échec. Mais je n'avais jamais vu la structure d'incitation formulée aussi explicitement. Goldman Sachs était essentiellement pénalisée à l'avance pour sa prudence.

L'Apple Card a été lancée le 20 août 2019. Des équipes internes chez Goldman avaient signalé des inquiétudes sur la maturité du système. Les files de messages entre l'application Wallet et le back-end de Goldman étaient insuffisamment testées. Les protocoles de synchronisation étaient fragiles. Mais le calcul était simple : livrer maintenant et corriger plus tard, ou payer 25 millions de dollars et corriger d'abord.

Ils ont livré. Et pendant plus d'un an, le système a fonctionné avec un trou que personne ne pouvait voir de l'extérieur.

Je pense à cela quand on me demande pourquoi Veriprajna insiste sur la vérification formelle avant le déploiement. « N'est-ce pas lent ? » me demande-t-on. « Ne pouvez-vous pas simplement surveiller en production et détecter les problèmes ? » Bien sûr. Vous pouvez aussi conduire sans freins en prévoyant de contourner les obstacles. Ça marche jusqu'à ce que ça ne marche plus. Et quand ça ne marche pas dans les services financiers, de vraies personnes en souffrent.

Pourquoi personne n'a-t-il rien vu ?

C'est la question qui me hante. Deux des entreprises les plus technologiquement sophistiquées de la planète — Apple, avec sa culture d'ingénierie légendaire, et Goldman Sachs, avec sa puissance de feu quantitative — et aucune des deux n'a remarqué que des milliers de contestations tombaient dans un trou noir ?

La réponse, je crois, est architecturale. Le système a été conçu comme un relais : Apple gère le front-end, Goldman gère le back-end, et les messages circulent entre les deux. Mais personne ne s'appropriait l'espace entre les deux systèmes. Personne n'avait de modèle formel de ce qui devait se passer lorsqu'une contestation entrait dans l'état A (« message soumis ») mais n'atteignait jamais l'état B (« formulaire complété »). Dans une machine à états bien conçue, c'est une transition que l'on prend explicitement en compte. Dans le système Apple Card, c'était une lacune que personne n'avait spécifiée, donc que personne ne surveillait.

J'ai eu une nuit blanche il y a environ un an — mon équipe et moi construisions un flux de conformité pour un client, et l'une de nos ingénieures, Priya, a signalé quelque chose de similaire. Elle modélisait les transitions d'états d'un processus de revue documentaire et a trouvé un chemin où une soumission pouvait rester bloquée indéfiniment dans un état « enrichissement en attente » si une API tierce expirait. Ce n'était pas un bug dans le code. Le code faisait exactement ce qu'on lui avait demandé. C'était un bug dans la conception — un état que la spécification n'avait pas prévu.

Nous l'avons détecté parce que nous utilisons des outils de vérification formelle — plus précisément, nous modélisons les flux de travail comme des machines à états et les faisons passer par des solveurs SMT qui vérifient exhaustivement chaque chemin possible. Le solveur a trouvé l'état mort de Priya en quelques secondes. Dans le système Apple Card, cet état mort a tourné en production pendant des mois.

La défaillance de l'Apple Card n'était pas un bug dans le code. Le code faisait exactement ce qu'on lui avait demandé. C'était un bug dans la conception — un état que personne n'avait spécifié, donc que personne ne surveillait.

Pourquoi ne pas simplement utiliser GPT pour ça ?

On me pose cette question en permanence. Un investisseur me l'a dite presque mot pour mot lors d'une réunion de présentation : « Pourquoi ne pouvez-vous pas simplement affiner GPT-4 sur la réglementation TILA et le laisser gérer les contestations ? »

J'ai pris une inspiration. Puis je lui ai demandé : « Si GPT-4 dit à un consommateur que sa contestation a été résolue, alors qu'en réalité elle n'a jamais été transmise à la banque, qui est responsable ? »

Il n'avait pas de réponse. Personne d'autre n'en a, parce que la question expose le problème fondamental de ce que j'appelle l'approche « méga-prompt » de l'IA dans les secteurs réglementés. Vous prenez un grand modèle de langage, vous entassez les réglementations pertinentes dans sa fenêtre de contexte et vous espérez qu'il gérera tout correctement. Aucune couche de gouvernance. Aucune vérification formelle. Aucune garantie mathématique que les sorties du système sont conformes à la loi.

Dans le cas de l'Apple Card, la défaillance était une erreur de logique dans une machine à états distribuée. Un wrapper LLM n'aurait pas corrigé cela — il aurait pu aggraver les choses. Imaginez un LLM disant avec assurance à un consommateur « Votre contestation a été soumise et fait l'objet d'une enquête » alors qu'en réalité, la contestation n'a jamais quitté les serveurs d'Apple. Ce n'est pas hypothétique. C'est à quoi ressemble l'hallucination dans un contexte financier, et c'est terrifiant.

Les sites de vulgarisation financière populaires et les contenus largement partagés sur l'IA dans la banque passent presque tous à côté de cette distinction. Ils parlent de l'IA qui « automatise » la conformité comme si le plus difficile était de lire les réglementations. Le plus difficile n'est pas de les lire. Le plus difficile est de prouver que votre système les respecte dans tous les scénarios possibles, y compris ceux auxquels vous n'avez pas encore pensé.

Pour un examen plus approfondi de la manière dont la défaillance Apple-Goldman se rattache à des violations réglementaires précises et à des lacunes architecturales, j'ai écrit une analyse interactive qui décortique l'ordonnance de consentement en détail.

Ce que « prouvablement correct » signifie vraiment

Quand je dis que Veriprajna construit des systèmes de conformité « prouvablement corrects », je ne veux pas dire « très bien testés ». Je veux dire mathématiquement prouvés. Il y a une différence, et elle compte énormément.

Les tests vérifient des scénarios précis. Vous écrivez un test qui dit : « si un utilisateur soumet une contestation et remplit le formulaire, vérifier qu'elle parvient à Goldman Sachs. » Ce test passe. Parfait. Mais vous n'avez pas testé le scénario où l'utilisateur soumet une contestation et ne remplit pas le formulaire. Ou celui où il le remplit mais où le réseau perd le paquet. Ou celui où deux contestations arrivent simultanément et où l'une écrase l'autre.

La vérification formelle ne vérifie pas des scénarios. Elle vérifie des propriétés. Vous définissez une propriété — « toute contestation soumise doit finir par atteindre un état d'enquête » — et un solveur mathématique prouve exhaustivement que la propriété est vraie dans toutes les exécutions possibles du système. Chaque chemin. Chaque cas limite. Chaque situation de concurrence. S'il existe un seul contre-exemple, le solveur le trouve et vous montre exactement comment le système peut échouer.

Nous utilisons des outils comme Imandra, qui nous permettent de construire ce qui est essentiellement un jumeau numérique de la logique de conformité. Le jumeau tourne en parallèle du système de production, et si le code de production tente une action qui s'écarte du modèle vérifié — comme abandonner une contestation à cause d'une étape d'interface incomplète — le système le détecte en temps réel.

C'est le genre d'approche qui aurait permis de détecter le bug de l'Apple Card avant qu'un seul consommateur ne soit touché. Dès la phase de conception, un solveur SMT aurait immédiatement identifié que la variable « CompletedFormB » n'était pas un champ obligatoire au sens de la TILA. La logique de transmission l'exigeait, mais la loi non. Cette discordance est un défaut prouvable, et elle aurait été signalée avant le déploiement.

L'architecture que nous construisons réellement

Je veux être précis sur ce à quoi ressemble en pratique un système de conformité « deep AI », car les affirmations vagues sur la « conformité pilotée par l'IA » font partie du problème.

Veriprajna utilise une architecture multi-agents. Au lieu d'une IA monolithique qui essaie de tout faire, nous déployons des agents spécialisés avec des rôles et des limites définis. Voyez cela moins comme recruter un génie que comme constituer une équipe où chacun a une tâche précise et un superviseur qui contrôle son travail.

Un agent d'admission gère la partie humaine et désordonnée — l'analyse des contestations en langage naturel. Quand quelqu'un écrit « Je n'ai jamais acheté ce café à Seattle ; j'étais à Londres ce jour-là », l'agent extrait les entités clés : la transaction, le commerçant, la date, la nature de la réclamation. C'est là que les LLM excellent véritablement.

Mais ensuite — et c'est là que nous divergeons de toutes les approches par wrapper que j'ai vues — les informations extraites passent à un moteur de politiques symbolique qui ne prédit ni ne devine. Il évalue la contestation à l'aune d'encodages en logique du premier ordre de la loi fédérale. Ce message contient-il assez d'informations pour constituer un avis d'erreur de facturation valide au sens de la TILA ? Le moteur n'estime pas. Il prouve.

Un agent de flux de travail impose la séquence des opérations. Un agent de vérification exécute des contrôles mathématiques en temps réel. Un agent d'audit consigne chaque interaction dans ce que nous appelons une « boîte de verre » — une transparence totale pour les régulateurs.

Et surtout, un agent sentinelle surveille précisément le type d'état mort qui a tué le système Apple Card. Si une contestation reste dans l'état « soumise mais non transmise » au-delà d'un seuil défini, la sentinelle n'attend pas qu'un humain s'en aperçoive. Elle détermine de façon autonome si les informations existantes suffisent pour avancer, les empaquette et les transmet par un canal vérifié.

Dans un système conçu pour une conformité absolue, c'est la loi — et non l'interface — qui détermine si une contestation est valide. Si un consommateur vous a signalé un débit non autorisé, l'absence de formulaire complété est votre problème, pas le sien.

Pourquoi le respect des délais est une obligation légale, pas un indicateur de performance

Il y a une autre dimension que la plupart des discussions techniques manquent complètement. Dans la conformité financière, le temps est la loi. La Regulation Z ne dit pas seulement que vous devez enquêter sur les contestations. Elle dit que vous devez en accuser réception dans des délais précis et les résoudre sous 60 jours. Goldman Sachs a été sanctionnée en partie parce qu'elle n'a pas envoyé les accusés de réception dans ces fenêtres.

Mon équipe a passé des mois à développer ce que nous appelons l'analyse de latence symbolique — une manière de prouver mathématiquement qu'un système distribué achèvera son travail dans le délai réglementaire, dans les conditions les plus défavorables. Pas dans des conditions moyennes. Pas au « 95e centile ». Dans le pire des cas.

La supervision traditionnelle vous dit si votre système a été lent. La latence symbolique vous dit si votre système peut être lent. Si une modification du code de l'interface porte le temps de traitement dans le pire des cas au-delà de la fenêtre réglementaire de 60 jours, le déploiement est automatiquement rejeté. Vous ne l'apprenez pas après coup. Vous l'apprenez avant de livrer.

Je me souviens du débat que nous avons eu en interne pour savoir si ce niveau de rigueur était nécessaire. L'un de mes ingénieurs — un type brillant qui avait passé des années chez un grand fournisseur de cloud — s'y est opposé avec force. « Tu ajoutes des semaines au cycle de déploiement pour un scénario qui n'arrivera peut-être jamais », a-t-il dit. J'ai pointé l'ordonnance de consentement de l'Apple Card. « C'est arrivé », ai-je répondu. « À Apple. À Goldman Sachs. À des dizaines de milliers de consommateurs qui n'avaient rien fait de mal. »

Il n'a plus discuté après ça.

Pour le détail technique complet de notre approche de la vérification formelle, y compris la méthodologie Performal pour les bornes de latence, voir notre article de recherche.

« Mais cela prendrait trop de temps à construire »

Les gens objectent toujours sur ce point, et je comprends pourquoi. L'Apple Card a été lancée en quelques mois. Une architecture de conformité formellement vérifiée demande 18 à 36 mois pour une optimisation complète dans un environnement chargé de systèmes hérités. Cela paraît une éternité dans un monde où les concurrents livrent chaque semaine.

Mais laissez-moi recadrer le calcul. Apple et Goldman Sachs ont passé des années à construire et à lancer l'Apple Card. Puis ils ont passé des années à en gérer les retombées — enquêtes internes, examens réglementaires, frais juridiques, dommages réputationnels et, au bout du compte, 89,8 millions de dollars de pénalités et d'indemnisations aux consommateurs. L'approche « rapide » n'était pas rapide. C'était de la vitesse en amont et une catastrophe en aval.

Notre approche de déploiement par phases tient compte de la réalité. On ne peut pas arracher les systèmes centraux d'une banque. Les mainframes COBOL qui tournent depuis les années 1980 ne vont pas disparaître du jour au lendemain. Nous intégrons donc par couches : auditer l'architecture existante, construire une passerelle d'API intelligente, faire tourner le système d'IA en mode fantôme pour valider les sorties du système hérité, et transférer progressivement le pouvoir de décision à mesure que les preuves formelles s'accumulent.

La première phase — évaluation et modélisation formelle — prend 14 à 20 semaines. À la fin, vous disposez d'un modèle mathématique de votre logique de conformité capable de détecter le type de bugs d'états morts qui ont miné l'Apple Card. Ce n'est pas 36 mois. C'est moins de cinq mois pour un système fondamentalement plus sûr.

Le moment qui a changé ma façon de voir les choses

Il y a un moment précis auquel je reviens sans cesse. C'était il y a environ huit mois, et nous menions une preuve de concept pour un client des services financiers. Nous avions modélisé leur flux de résolution des contestations comme une machine à états distribuée et nous exécutions la suite de vérification formelle.

Le solveur a trouvé onze états morts.

Onze chemins à travers le système où la plainte d'un consommateur pouvait rester bloquée sans résolution ni alerte. L'équipe d'ingénierie du client faisait tourner ce système depuis trois ans. Ils avaient traité des millions de transactions. Ils avaient des tableaux de bord de supervision, des systèmes d'alerte, des audits trimestriels. Et rien de tout cela n'avait détecté ces onze trous.

La salle est devenue silencieuse quand je leur ai montré les résultats. Leur responsable de la conformité — une femme qui avait passé vingt ans dans la réglementation bancaire — a regardé l'écran et a dit : « Combien de consommateurs sont tombés dans ces états ? »

Nous ne le savions pas. Eux non plus. C'est là le propre des états morts dans les systèmes distribués : si personne ne les guette, ils sont invisibles. Les consommateurs touchés ont peut-être appelé le service client, se sont fait balader et ont fini par abandonner. Ou bien ils paient peut-être encore des débits qu'ils n'ont jamais effectués.

Voilà à quoi ressemble la défaillance de l'Apple Card vue de l'intérieur. Pas une explosion spectaculaire. Une accumulation lente et silencieuse de préjudices que personne ne peut voir jusqu'à ce qu'un régulateur force l'ouverture de la boîte noire.

À quoi ressembleront les cinq prochaines années

L'action du CFPB contre Apple et Goldman Sachs n'est pas un événement isolé. C'est le début d'une remise en cause réglementaire de la manière dont les entreprises technologiques gèrent l'infrastructure financière. À mesure que la banque s'intègre davantage — dans les téléphones, dans les applications, dans des plateformes qui n'avaient pas été conçues à l'origine comme des services financiers — l'écart entre « fonctionne la plupart du temps » et « fonctionne prouvablement tout le temps » devient une responsabilité qui se chiffre en centaines de millions de dollars.

Je pense à l'objection que j'entends le plus souvent : « La vérification formelle n'est-elle pas excessive pour la plupart des systèmes financiers ? » Et ma réponse est devenue plus simple avec le temps. L'Apple Card est l'un des produits financiers grand public les plus visibles au monde, construit par deux entreprises aux ressources d'ingénierie pratiquement illimitées. Si elles n'ont pas su détecter un état mort dans un flux de contestations avec des tests et une supervision classiques, qu'est-ce qui vous fait croire que votre système est différent ?

Le secteur s'oriente vers ce que j'appelle la conformité absolue — non pas la conformité comme exercice de cases à cocher, mais la conformité comme propriété architecturale. Un système où le respect de la loi n'est pas quelque chose que l'on vérifie après coup, mais quelque chose que l'on prouve avant le déploiement. Où l'écart entre l'interface et la réglementation est comblé non par la vigilance humaine, mais par la certitude mathématique.

L'ère du « livrer vite et corriger plus tard » est incompatible avec les exigences « déplacer de l'argent et protéger les gens » de la finance mondiale. L'Apple Card l'a prouvé. La question est de savoir si le secteur tirera la leçon avant ou après la prochaine amende de 89 millions de dollars.

Nous construisons cet avenir chez Veriprajna. Pas parce que c'est facile — la vérification formelle des systèmes financiers distribués est réellement difficile, et quiconque vous dit le contraire a quelque chose à vendre. Mais parce que l'alternative, c'est ce que nous avons vu en octobre 2024 : deux des entreprises les plus puissantes du monde, un bouton cassé, et des dizaines de milliers de personnes laissées à payer la facture de débits qu'elles n'ont jamais effectués.

Ce n'est pas un problème de technologie. C'est un problème d'éthique de l'ingénierie. Et la solution n'est pas une meilleure supervision ou des correctifs plus rapides. C'est de construire des systèmes corrects par construction — des systèmes où les mathématiques garantissent que la contestation d'aucun consommateur ne disparaîtra jamais dans le vide.

L'amende de 89 millions de dollars est déjà payée. Le vrai coût, c'est la confiance qui a été brisée. La reconstruire exige plus que des promesses. Elle exige des preuves.