Knight Capital : 45 minutes, un serveur non mis à jour et plus de 460 millions de dollars

Le 1er août 2012, Knight Capital a perdu plus de 460 millions de dollars en environ 45 minutes. Selon le régulateur, tout a commencé par un changement de logiciel installé sur sept serveurs sur huit. Le huitième est resté avec un vieux code qui ne servait plus, et ce code s'est réveillé à l'ouverture de la Bourse. Ce qui a suivi, c'est une chaîne de contrôles qui n'étaient pas là où il en fallait.

C'est un cas largement documenté dans des registres publics : la Securities and Exchange Commission des États-Unis (la SEC, le régulateur des marchés de ce pays) l'a instruit et a publié ses conclusions dans une ordonnance de 18 pages [1]. Presque tout ce qui suit en vient. Une nuance importante : Knight a accepté l'accord avec la SEC sans admettre ni nier ces conclusions [1, section II].

Cet article s'adresse à celles et ceux qui dirigent une entreprise ou une direction technologique. Il couvre quatre points :

1. Ce qui s'est passé, heure par heure.
2. Pourquoi ce n'était pas de la malchance, mais une chaîne de petites décisions.
3. Ce qu'un dirigeant en retient, en langage d'affaires.
4. Quoi demander à votre prochain comité et par où commencer cette semaine.

Une précision avant de commencer : Hábil n'a pas participé à ce cas. Nous le racontons à partir de ce que la SEC et Knight elle-même ont communiqué publiquement.

Premièrement, qui était Knight

Knight Capital était l'une des plus grandes firmes de Wall Street pour l'exécution d'ordres sur actions. Selon la SEC, en 2011 et 2012, son activité représentait, en général, environ 10 % de toutes les actions négociées sur les marchés cotés des États-Unis [1]. Quand un petit investisseur achetait des actions par l'intermédiaire de son courtier, l'ordre passait souvent par Knight.

Pour cela, la firme utilisait un système appelé SMARS : un routeur d'ordres automatique, à haute vitesse. Son rôle est simple à expliquer. Il reçoit un ordre d'achat ou de vente (l'ordre « parent ») et, selon ce qui est disponible sur le marché, envoie un ou plusieurs ordres dérivés (les ordres « enfants ») vers différents centres de négociation (bourses et autres marchés où s'achètent et se vendent des actions) pour l'exécuter [1, par. 12]. Logiquement, une fois l'ordre parent terminé, il cesse d'envoyer des ordres enfants.

Cette dernière idée est celle qui compte. Gardez-la en tête.

La chronologie, heure par heure

2003 : une fonction que personne n'éteint

Knight cesse d'utiliser une fonction de SMARS appelée « Power Peg ». Elle cesse de s'en servir, mais ne la supprime pas. Le code reste dans le système, présent et prêt à être activé [1, par. 13–14].

Dans ce code se trouvait une pièce clé : un compteur qui additionnait combien d'actions de l'ordre parent avaient déjà été exécutées. Ce compteur était le frein. Il disait au système : « c'est complet, arrête d'envoyer ».

2005 : un changement que personne ne reteste

Deux ans plus tard, l'équipe déplace ce compteur ailleurs dans SMARS pour s'en servir dans une autre fonction. Personne ne reteste Power Peg pour vérifier qu'il fonctionne encore sans lui [1, par. 14]. À quoi bon, si plus personne ne s'en sert ?

Dès ce jour, Power Peg est une voiture sans freins garée au garage. Personne ne la conduit. Personne ne la vérifie. Les clés sont sur le contact.

Juillet 2012 : huit serveurs, sept copies

La Bourse de New York (NYSE) s'apprête à lancer un programme pour les ordres de petits investisseurs, le Retail Liquidity Program, qui démarre le 1er août [1, par. 12]. Knight veut que ses clients y participent dès le premier jour ; elle écrit donc du nouveau code pour SMARS.

Deux décisions techniques préparent le piège :

• Le nouveau code remplace l'ancien Power Peg dans cette partie du système.
• Pour s'activer, il réutilise le même drapeau (un interrupteur à l'intérieur de chaque ordre) qui, des années plus tôt, allumait Power Peg [1, par. 13]. L'idée était de supprimer Power Peg, de sorte que ce drapeau ne puisse plus allumer que le nouveau code.

À partir du 27 juillet, un technicien installe le nouveau code par étapes, serveur après serveur, sur des jours successifs. SMARS tourne sur huit serveurs. Sur l'un d'eux, le nouveau code n'est pas copié [1, par. 15].

Personne ne s'en aperçoit. Selon la SEC, Knight n'exigeait pas qu'un second technicien revoie l'installation et ne disposait d'aucune procédure écrite qui l'impose [1, par. 15 et 26]. Le huitième serveur reste avec Power Peg à l'intérieur et sans le nouveau code.

Mercredi 1er août, 8 h 01 du matin (heure de New York) : 97 courriels que personne ne lit

Il reste presque une heure et demie avant l'ouverture du marché. Des ordres du nouveau programme, marqués pour être exécutés avant l'ouverture, arrivent. Vers 8 h 01, un système interne de Knight commence à envoyer des courriels automatiques à un groupe du personnel. Ils mentionnent SMARS et signalent une erreur : « Power Peg disabled », Power Peg désactivé [1, par. 19].

Avant 9 h 30, 97 de ces courriels arrivent. Personne n'agit. Ce n'est pas la négligence d'une personne : ces messages n'avaient pas été conçus comme des alertes, et le personnel, en général, ne les examinait pas à leur réception [1, par. 19]. La SEC le formule ainsi : c'étaient des messages en temps réel, causés par l'installation ratée, et ils offraient une possible occasion de trouver et de corriger le problème avant l'ouverture [1, par. 19].

Le système a prévenu. L'avertissement est arrivé dans une boîte que personne ne regardait.

9 h 30 : le marché ouvre

La cloche sonne. Sept serveurs traitent correctement les ordres du nouveau programme. Le huitième, non.

Chaque ordre portant le drapeau réutilisé qui arrive sur ce serveur réveille Power Peg. Et Power Peg n'a plus son compteur : il ne sait pas quand l'ordre parent est terminé. Alors il envoie des ordres enfants sans s'arrêter, l'un après l'autre, à toute vitesse, pour chaque ordre qu'il reçoit [1, par. 16].

Le plus troublant : une autre partie du système de Knight savait que les ordres étaient déjà terminés. Mais cette information n'arrivait pas jusqu'à SMARS [1, par. 16].

Rappelez-vous l'idée que je vous ai demandé de garder. La donnée qui aurait servi de frein existait ailleurs dans le système ; pas dans la partie qui envoyait.

Les minutes suivantes : chercher à l'aveugle

Dès l'ouverture, du personnel de haut niveau de Knight voit, dans son outil de supervision, une position énorme s'accumuler dans un compte interne, le « compte 33 » [1, par. 24–25] : des actions achetées ou vendues qui restent à la charge de Knight, avec tout leur risque. Il voit le symptôme. Il ne voit pas la cause.

La SEC décrit pourquoi il a fallu si longtemps pour comprendre ce qui se passait :

• L'outil de supervision dépendait entièrement d'une personne qui le regarde : il ne générait aucune alerte automatique sur l'exposition de la firme, c'est-à-dire l'argent qu'elle risquait de perdre [1, par. 25].
• Il n'affichait pas les limites : la personne qui le regardait devait connaître par cœur la limite de chaque compte pour constater qu'elle était dépassée [1, par. 25].
• Avec le volume de ce matin-là, il prenait du retard et ses rapports sortaient inexacts [1, par. 25].
• Le compte 33 avait une limite de 2 millions de dollars, mais n'était pas relié à des contrôles automatiques sur l'exposition totale de Knight ; et l'outil de supervision n'arrêtait pas non plus de lui-même l'envoi d'ordres [1, par. 23–25].
• Enfin, il n'existait pas de procédures pour guider le personnel lors d'un incident grave ; la SEC a conclu que l'équipe technique avait besoin d'une consigne claire sur le moment de déconnecter un système défaillant [1, par. 27 et 42].

Pendant ce temps, Knight reste connectée au marché. Son équipe technologique tente de trouver le problème en direct, alors que le système envoie des millions d'ordres [1, par. 10 et 27].

Le remède qui aggrave tout

Lors d'une de ses tentatives, l'équipe fait ce que beaucoup d'entre nous feraient : revenir à l'état précédent. Elle désinstalle le nouveau code des sept serveurs où il était bien installé [1, par. 27].

Mais sur ces sept serveurs, sous le nouveau code, Power Peg était encore là. En retirant le nouveau code, le drapeau rallume l'ancien. Ce sont maintenant huit serveurs qui envoient des ordres sans frein [1, par. 27].

Le retour arrière, qui devait être le filet de sécurité, a été la poussée finale, parce que personne ne savait avec certitude ce qu'il y avait dessous.

Environ 45 minutes plus tard

Quand Knight cesse enfin d'envoyer des ordres, le bilan de la SEC est le suivant [1, par. 1 et 17] :

• 212 ordres de détail (de petits investisseurs) ont tout déclenché.
• SMARS a envoyé des millions d'ordres enfants, avec plus de 4 millions d'exécutions sur 154 actions et plus de 397 millions de titres.
• Knight s'est retrouvée, sans l'avoir voulu, avec une position nette acheteuse d'environ 3 500 millions de dollars sur 80 actions et une position nette vendeuse d'environ 3 150 millions sur 74 actions.

Les dégâts ne sont pas restés chez Knight. Sur 75 de ces actions, ses opérations ont représenté plus de 20 % du volume et ont contribué à des variations de prix de plus de 5 % ; sur 37, le prix a bougé de plus de 10 % et Knight a représenté plus de la moitié du volume [1, par. 18]. Ces exécutions ont touché d'autres participants du marché : certains ont reçu des prix moins favorables et d'autres, plus favorables, que ceux qu'ils auraient eus sans elles.

Les jours suivants

• Jeudi 2 août. Knight annonce une perte avant impôts d'environ 440 millions de dollars [3]. Ce matin-là, selon l'Associated Press, son action perd la moitié de sa valeur en début de séance [5].
• Lundi 6 août. Un groupe d'investisseurs convient d'injecter 400 millions de dollars en échange d'actions de préférence convertibles (des actions assorties de droits particuliers, échangeables contre des actions ordinaires) [4]. Dans son rapport trimestriel, Knight elle-même reconnaît l'existence d'un « substantial doubt » quant à sa capacité à poursuivre son activité [6].
• 1er juillet 2013. Knight Capital Group et GETCO fusionnent pour former KCG Holdings ; Knight cesse d'être une entreprise indépendante [1, par. 11].
• 16 octobre 2013. La SEC lui inflige une amende de 12 millions de dollars. C'est la première action de la SEC au titre de sa règle d'accès au marché, adoptée en 2010 : la règle qui impose aux firmes des contrôles de risque avant d'envoyer des ordres sur le marché [1][2]. Le chiffre final de la perte retenu par la SEC est de plus de 460 millions de dollars [1, par. 1 et 10].

Une remarque sur les chiffres : les 440 millions sont l'estimation que Knight a publiée le lendemain [3] ; les plus de 460 millions sont ce que la SEC a établi à la fin de son enquête [1]. Nous retenons ici celle de la SEC.

Ce n'était pas de la malchance : c'était une chaîne

Il est tentant de raconter cette histoire comme « un technicien a oublié de copier un fichier ». La SEC ne la raconte pas ainsi. Son ordonnance pointe des défaillances de contrôle, pas d'une personne [1, par. 9 et 40–44]. Chacun de ces maillons, pris isolément, aurait rompu la chaîne :

Relisez la troisième ligne. Selon le régulateur, a simple double-check du déploiement « could have identified that a server had been missed and averted the events of August 1 » [1, par. 41].

Et il y a un détail qui devrait gêner tout comité : Knight avait des contrôles. Son interface client, son système interne d'ordres et son système d'exécution interne disposaient de contrôles contre les ordres erronés [1, par. 20]. Le problème, c'est qu'ils se trouvaient en amont de SMARS. Sur le dernier tronçon, celui qui touchait le marché, il n'y en avait pas de suffisant [1, par. 21].

L'avertissement arrivé un an plus tôt

En octobre 2011, Knight a réalisé un essai de reprise après sinistre un week-end, avec des données de test. Le lundi, l'un de ses systèmes a continué à utiliser ces données de test pour coter sur le marché réel. Il a perdu près de 7,5 millions de dollars [1, par. 33].

Knight a corrigé ce problème : elle a limité les horaires du système, modifié un contrôle et ajouté une étape à une liste de vérification. Ce qu'elle n'a pas fait, dit la SEC, c'est se demander si elle disposait de contrôles suffisants contre les ordres erronés quel que soit le système qui les envoie et pour quelque raison que ce soit [1, par. 33 et 44]. Elle a réagi au cas, pas à la cause.

La signature qui disait autre chose

En mars 2012, le directeur général de Knight a signé l'attestation annuelle qu'exige la règle d'accès au marché. Le texte ne disait pas que les contrôles respectaient la règle ; il disait que Knight avait en place des « processes » pour la respecter. C'était une erreur de rédaction involontaire, le directeur ne l'a pas remarquée et croyait signer que tout était conforme [1, par. 34]. Pour la SEC, déclarer que des « processes » existent n'équivaut pas à déclarer que les contrôles et procédures sont raisonnablement conçus et conformes à la règle [1, par. 45].

En réunion, cela ressemble à un point technique. Cette différence n'explique pas à elle seule ce qui s'est passé le 1er août, mais elle révèle une supervision qui tenait pour acquis que les contrôles suffisaient sans le vérifier.

Ce qu'un dirigeant en retient

Vous n'exploitez pas un routeur d'actions. Mais si votre entreprise encaisse, facture, accorde des crédits, émet des polices ou vend en ligne, vous avez des systèmes qui agissent seuls et vite. Ces leçons ne sont pas celles de Wall Street ; ce sont celles de toute activité qui ne peut pas s'arrêter.

1. Le risque le plus coûteux n'est pas dans le code neuf : il est dans celui que personne ne se rappelle

Power Peg n'avait pas servi depuis neuf ans. Personne n'y voyait un risque parce qu'il « ne faisait rien ». Dans les systèmes qui ont des années derrière eux, il est courant que restent des fonctions éteintes, des drapeaux réutilisés et des intégrations sans responsable clair. Ce qui ne sert plus et n'est pas supprimé est une dette qui porte intérêt le pire jour.

2. Un changement installé à la main n'est pas un changement maîtrisé

Le problème n'était pas qu'une personne se trompe : les personnes se trompent. Le problème, c'est que rien n'était conçu pour détecter l'erreur. Si installer sur huit serveurs dépend de quelqu'un qui répète huit fois la même chose sans faillir, tôt ou tard l'une de ces répétitions tournera mal. Une chaîne de mise en production automatisée (le processus qui amène chaque changement jusqu'aux serveurs sans étape manuelle) réduit cette variation : elle installe la même chose partout et vérifie que le résultat est identique. Elle n'élimine pas le risque, mais elle le rend visible.

3. Une alerte que personne ne lit est un journal, pas un contrôle

Les 97 courriels sont la scène qui devrait le plus empêcher un dirigeant de dormir. Le système a bien détecté le problème, avec une heure et demie d'avance. Mais l'avertissement n'était pas conçu pour que quelqu'un agisse. Demandez-vous combien d'avertissements automatiques de votre exploitation arrivent aujourd'hui dans une boîte partagée que personne ne consulte.

4. Le frein doit être là où est le risque, et il doit être automatique

Knight avait des contrôles au début du parcours et de la supervision après les faits. Il lui manquait un frein juste avant que l'argent ne sorte, et des limites qui arrêtent l'envoi d'elles-mêmes. Une limite qui dépend de quelqu'un qui s'en souvient en regardant un écran lent n'est pas une limite.

5. Revenir en arrière est aussi un changement, et il faut aussi le répéter

La tentative de revenir à la version précédente a tout aggravé, parce que personne ne savait ce qu'il y avait dessous. Un retour arrière sûr n'est pas « désinstaller et prier » : c'est une procédure testée à l'avance, qui mène à un état connu.

6. Dans un incident, la première décision est une décision d'affaires : déconnectons-nous ?

Pendant 45 minutes, l'équipe technique a cherché la panne avec le système connecté. La SEC relève que Knight avait besoin d'une consigne claire sur le moment de déconnecter [1, par. 42]. Cette décision ne doit pas s'improviser en plein incendie ni dépendre de la personne qui tient le clavier : elle se convient à l'avance, avec un nom et un prénom, et un seuil clair.

7. Corriger le symptôme n'est pas corriger la cause

La perte de 7,5 millions de 2011 était un avertissement. Knight a réglé ce cas précis et a continué comme avant. Chaque petit incident est l'occasion la moins chère de trouver le gros.

Pourquoi cela continue d'arriver

Plus de quatorze ans ont passé et la leçon reste d'actualité pour une raison inconfortable : aucun de ces contrôles ne demande une technologie exotique. Une double vérification, une alerte bien dirigée, une limite automatique, une procédure pour déconnecter. Ils combinent processus, technologie et gouvernance, et leur vraie difficulté est ailleurs : ils entrent en concurrence avec la précipitation. Knight avait une date fixe, le lancement du programme de la Bourse, et voulait être prête ce jour-là [1, par. 12].

Quand le calendrier commande, ce qui est coupé d'abord, c'est ce qui « ne se voit pas » : la revue, le test de l'ancien code, la répétition du retour arrière. Jusqu'à ce que cela se voie.

Cinq questions pour votre prochain comité

1. Comment un changement arrive-t-il dans nos systèmes critiques ? Par une chaîne automatisée qui installe la même chose partout et le vérifie, ou parce que quelqu'un le copie à la main ?
2. Quel code ou quelles fonctions éteintes restent dans nos systèmes, et qui répondrait si quelqu'un les rallumait sans le vouloir ?
3. Quels avertissements automatiques nos systèmes génèrent-ils aujourd'hui, à qui parviennent-ils et qui est tenu d'agir lorsqu'ils apparaissent ?
4. Quelles limites d'argent, de volume ou de quantité arrêtent d'elles-mêmes une opération anormale, et à quel point exact du parcours se trouvent-elles ?
5. Si demain un système se met à causer des dégâts, qui décide de le déconnecter, avec quel seuil, et quand avons-nous répété pour la dernière fois le retour arrière ?

Si une réponse est « je ne sais pas » ou « ça dépend de qui est là », transformez-la en un risque avec un responsable et une date. Pour chacune, demandez cinq éléments : le système concerné, son responsable, la preuve qui existe aujourd'hui, l'impact en cas de défaillance et le prochain contrôle nécessaire. Avec cela, votre comité peut prioriser un premier système et décider de la suite.

Par où commencer cette semaine

Choisissez un système qui encaisse, paie ou déplace de l'argent. Demandez à la personne qui le met en production de vous raconter, étape par étape, comment s'est passé le dernier changement : qui l'a installé, sur combien de serveurs, comment il a été vérifié que le résultat était identique partout et ce qui se serait passé en cas d'échec. Si la réponse contient un « normalement » ou un « il connaît la procédure », vous savez par où commencer.

Ce que fait Hábil

Hábil est un cabinet mexicain d'ingénierie, fondé en 2006, qui construit des systèmes pour des activités qui ne peuvent pas s'arrêter. L'un des problèmes que nous résolvons est justement celui de cette histoire : que la mise en production d'un changement cesse de faire peur.

Nous concevons et mettons en place des chaînes de mise en production automatisées dans le cloud, sur vos serveurs ou dans les deux : chaque changement passe par le même chemin, avec des tests et une revue de sécurité avant d'atteindre vos clients, des environnements de test et d'exploitation qui se ressemblent, un retour arrière convenu et une traçabilité de qui a approuvé quoi. Nous commençons par les outils que votre équipe utilise déjà et par le système qui vous fait le plus mal, sans arrêter l'exploitation. Consultez la page Passer à la production vite et sans mauvaises surprises et, si vous voulez le détail technique, l'article CI/CD DevSecOps sur votre propre infrastructure.

Si vous voulez confronter ces cinq questions à un système concret, commençons par là. Demandez votre première conversation, sans frais. Nous examinons comment l'un de vos systèmes prioritaires est mis en production aujourd'hui et vous repartez avec une première carte de vos risques et votre prochaine décision. Écrivez-nous sur WhatsApp.

Questions fréquentes

Knight Capital a-t-elle fait faillite ?

Pas exactement. Elle a survécu grâce à une injection de 400 millions de dollars d'un groupe d'investisseurs, convenue cinq jours plus tard [4], mais elle a perdu son indépendance : en juillet 2013, elle a fusionné avec GETCO pour former KCG Holdings [1, par. 11].

Était-ce la faute du technicien qui n'a pas copié le code ?

La SEC ne le présente pas ainsi. Son ordonnance relève que Knight n'avait ni procédures écrites ni seconde revue pour installer du code sur ce système, ni contrôles pour empêcher l'activation de code inutilisé [1, par. 9-D, 15 et 26]. Une erreur humaine est prévisible ; ce qui a manqué, c'est un système qui la détecte.

Pourquoi deux chiffres circulent-ils, 440 millions et 460 millions ?

Les 440 millions sont la perte avant impôts que Knight a estimée le 2 août 2012 [3]. La SEC, en clôturant son enquête en octobre 2013, a établi une perte de plus de 460 millions [1].

Cela ne concerne-t-il que les entreprises financières ?

Non. Toute entreprise dont les systèmes agissent seuls (encaissements, facturation, paiements, stocks, commandes en ligne) a la même exposition : un changement mal installé, du code oublié et des avertissements que personne ne traite. Ce qui change, c'est la vitesse à laquelle l'erreur se transforme en argent.

Automatiser les mises en production élimine-t-il le risque ?

Non ; il le réduit et le rend visible. Une chaîne automatisée installe la même chose partout, vérifie le résultat et laisse une trace, mais elle a encore besoin de tests, de limites automatiques, d'alertes que quelqu'un traite et d'un retour arrière répété.

Par où commence une entreprise qui met aujourd'hui en production à la main ?

Par un seul système, celui qui déplace le plus d'argent ou qui fait le plus mal, en mesurant d'abord comment la mise en production se passe aujourd'hui. À partir de là, l'automatisation se fait par étapes, sans arrêter l'exploitation.

Les chiffres et les faits du cas proviennent de documents publics consultés le 20 octobre 2026. Les citations sont reproduites dans leur anglais d'origine.