Knight Capital : le courtier ruiné en 45 minutes par une mise en production incomplète

Qui était Knight Capital avant le 1er août 2012 ?

Knight Capital Group est une société de courtage fondée en 1995 et introduite en Bourse en 1998, rappelle le New York Times (DealBook) du 2 août 2012. Installée à Jersey City, dans le New Jersey, elle fait surtout de la tenue de marché : elle achète et vend des actions en continu, avec son propre capital, et exécute les ordres que lui transmettent des courtiers en ligne comme TD Ameritrade ou E*Trade. Son entité opérationnelle aux États-Unis, Knight Capital Americas, est un courtier enregistré auprès de la SEC, l'autorité fédérale des marchés financiers.

Son poids sur le marché américain est considérable. D'après l'ordonnance de la SEC du 16 octobre 2013, les transactions de Knight, pour elle-même et pour ses clients, représentaient en 2011 et 2012 environ 10 % de tous les échanges d'actions cotées aux États-Unis. Le cabinet Tabb Group, cité par le New York Times, l'estimait à 11 % entre janvier et mai 2012. Le même article indique qu'à la fin du premier trimestre 2012, la société employait 1 418 personnes dans 21 implantations.

Les comptes 2011, republiés par Knight auprès de la SEC le 6 août 2012, montrent une entreprise rentable : 1,40 milliard de dollars de revenus, 115,2 millions de bénéfice net et 1,46 milliard de capitaux propres au 31 décembre 2011. L'année 2012 avait mal commencé : lors de l'introduction en Bourse de Facebook, en mai, Knight a enregistré 35,4 millions de dollars de pertes de négociation, imputées aux défaillances du Nasdaq, selon son rapport annuel 2012.

Au cœur de l'histoire se trouve SMARS, un routeur d'ordres automatique, rapide et algorithmique. L'ordonnance de la SEC décrit son rôle : recevoir de grands ordres, dits « parents », venus des autres systèmes de Knight, puis les découper en petits ordres « enfants » envoyés aux différentes Bourses jusqu'à ce que la quantité demandée soit exécutée. SMARS représentait à lui seul environ 1 % ou plus des échanges d'actions cotées aux États-Unis. Pour une PME, l'équivalent serait le module qui transforme une commande en paiements, en bons de livraison et en messages : un composant invisible dont tout le reste dépend.

Depuis le 14 juillet 2011, une règle de la SEC encadre ce type d'activité. La règle 15c3-5, adoptée le 3 novembre 2010 selon le communiqué de la SEC, oblige tout courtier qui accède directement au marché à mettre en place des contrôles empêchant les ordres erronés et le dépassement de plafonds de capital fixés d'avance. Elle exige aussi une description écrite de ces contrôles, une revue régulière de leur efficacité et une certification annuelle signée par le directeur général.

Que s'est-il passé dans les serveurs de Knight avant l'ouverture du 1er août 2012 ?

Le point de départ est un changement de règles du marché. Le 3 juillet 2012, la SEC approuve, par sa décision n° 34-67347, le Retail Liquidity Program de la Bourse de New York, un dispositif à l'essai pendant douze mois qui offre des conditions particulières aux ordres des particuliers. Knight avait d'ailleurs adressé à la SEC des lettres de commentaires sur ce projet en novembre 2011 et en mars 2012. Pour que ses clients puissent y participer dès le 1er août, elle modifie plusieurs systèmes, dont SMARS.

Le nouveau code devait prendre la place d'un code inutilisé dans la même partie du routeur : celui de Power Peg, une fonction que Knight n'employait plus depuis 2003 mais qui était restée présente et appelable. L'équipe réutilise aussi un indicateur, un « drapeau » transmis avec les ordres, qui servait autrefois à déclencher Power Peg. L'intention, écrit la SEC, était de supprimer Power Peg pour que ce drapeau active désormais la nouvelle fonction. Tout reposait donc sur une condition : que l'ancien code ait disparu de chaque serveur.

Or Power Peg n'était plus fiable depuis longtemps. Lorsqu'il fonctionnait, un compteur additionnait les actions exécutées et arrêtait l'envoi d'ordres enfants une fois l'ordre parent entièrement servi. En 2005, Knight a déplacé ce compteur plus tôt dans la séquence du code pour l'utiliser ailleurs, sans retester Power Peg. L'ordonnance le dit simplement : personne n'a vérifié si la vieille fonction marcherait encore correctement si on l'appelait un jour. Le code mort était devenu un code dangereux, sans que rien ne le signale.

À partir du 27 juillet 2012, Knight déploie le nouveau code par étapes, sur un nombre limité de serveurs chaque jour. L'un des techniciens ne copie pas le code sur l'un des huit serveurs de SMARS. Aucun second technicien ne contrôle le déploiement, et aucune procédure écrite ne l'exige : SMARS n'en avait pas, alors que d'autres équipes de Knight disposaient de procédures écrites. Personne ne s'aperçoit que le huitième serveur conserve Power Peg et ne contient pas le nouveau code.

Le matin du 1er août, le problème se manifeste avant même l'ouverture. Dès 8 h 01, heure de New York, des ordres reçus pour la séance de pré-ouverture font générer par un système interne des e-mails automatiques, appelés « BNET rejects », qui mentionnent SMARS et une erreur intitulée « Power Peg disabled ». Quatre-vingt-dix-sept de ces messages partent vers un groupe d'employés avant 9 h 30. Ils n'avaient pas été conçus comme des alertes et n'étaient généralement pas lus. La SEC note qu'ils offraient pourtant une occasion de trouver et de corriger l'erreur avant l'ouverture.

Comment 212 ordres de clients sont-ils devenus 4 millions d'exécutions en 45 minutes ?

À 9 h 30, Knight reçoit des ordres de courtiers dont les clients peuvent participer au nouveau programme. Les sept serveurs mis à jour les traitent correctement. Sur le huitième, les ordres porteurs du drapeau réutilisé déclenchent Power Peg. Comme le compteur n'est plus à sa place, ce serveur envoie en rafale des ordres enfants pour chaque ordre parent, sans tenir compte des actions déjà achetées ou vendues. Une autre partie du système de Knight savait que les ordres parents étaient servis, mais cette information ne parvenait pas à SMARS.

Pour 212 ordres parents, SMARS envoie des millions d'ordres enfants. En 45 minutes environ, Knight obtient plus de 4 millions d'exécutions sur 154 titres, pour plus de 397 millions d'actions. Elle se retrouve avec une position acheteuse nette d'environ 3,5 milliards de dollars sur 80 titres et une position vendeuse nette d'environ 3,15 milliards sur 74 autres, détaille l'ordonnance. Ces positions ne correspondent à aucune décision d'investissement : ce sont les traces d'une boucle qui ne savait plus s'arrêter.

Le marché en porte la marque. Sur 75 titres, les exécutions de Knight dépassent 20 % du volume échangé et accompagnent des variations de cours supérieures à 5 % ; sur 37 d'entre eux, elles dépassent la moitié du volume et le cours bouge de plus de 10 %. La SEC note que certains intervenants ont obtenu des prix moins favorables, d'autres des prix plus favorables. Le New York Times du 1er août 2012 rapporte que toutes les Bourses ont accepté d'annuler les transactions sur six titres aux mouvements extrêmes ; les autres sont restées valables.

Pendant ce temps, Knight reste connectée au marché. Elle n'a aucune procédure de gestion d'incident pour guider ses équipes et s'en remet surtout à son équipe technique, qui cherche la panne en pleine séance pendant que les ordres continuent de partir. Lors d'une de ses tentatives, elle désinstalle le nouveau code des sept serveurs où il fonctionnait. Le remède aggrave le mal : les ordres entrants activent alors Power Peg, toujours présent sur ces serveurs, comme sur le huitième. D'après le New York Times, l'agitation retombe vers 10 h 15.

Le lendemain, 2 août, Knight publie un communiqué déposé auprès de la SEC : le problème est lié à l'installation d'un logiciel de négociation, ce logiciel a été retiré, toutes les positions erronées ont été soldées et la perte réalisée avant impôt atteint environ 440 millions de dollars. Le capital est « gravement » atteint, même si les filiales de courtage respectent encore leurs exigences de fonds propres. La société dit chercher des solutions de financement. Elle affirme aussi que ses clients n'ont pas été lésés par les ordres erronés.

Pourquoi le retour à l'ancienne version a-t-il aggravé la situation ?

Revenir à la version précédente est le réflexe le plus répandu quand une mise en production tourne mal, et il est souvent le bon. Chez Knight, il a échoué pour une raison précise : la version précédente n'était pas saine. Elle contenait Power Peg, défectueux depuis 2005, et les ordres du jour portaient le drapeau qui le déclenchait. En retirant le nouveau code des sept serveurs, l'équipe a transformé un serveur fautif en huit serveurs fautifs.

Ce détail renverse une idée reçue. Un retour arrière n'est sûr que si l'on sait exactement ce que contient la version vers laquelle on revient et si elle est compatible avec les données qui circulent au moment du retour. Il se prépare donc avant la mise en production, et se teste, au lieu de s'improviser en pleine crise. Sans cette préparation, il devient un second déploiement, fait dans la précipitation, sans relecture.

L'ordonnance pointe une priorité qui aurait dû passer avant le diagnostic : couper le flux. Tant que SMARS restait connecté, chaque minute de recherche coûtait des millions d'ordres supplémentaires. Pour une entreprise de toute taille, la règle qui en découle est simple à écrire : quand un système envoie au-dehors des actions qu'on ne comprend pas, on l'arrête d'abord et on cherche ensuite, à condition d'avoir décidé à l'avance qui peut l'arrêter, comment, et ce que l'arrêt coupe.

Pourquoi trouve-t-on plusieurs montants pour la même perte ?

Les chiffres publiés ne se contredisent pas : ils ne mesurent pas la même chose. Le 2 août 2012, Knight annonce une perte réalisée avant impôt « d'environ » 440 millions de dollars, une première estimation. Dans ses résultats du troisième trimestre, publiés le 17 octobre 2012, elle chiffre la perte de négociation à 457,6 millions et l'ensemble des pertes avant impôt liées à l'incident, frais induits compris, à 461,1 millions. Son rapport annuel 2012 retient 468,1 millions en ajoutant les frais juridiques et de conseil engagés ensuite. La SEC, elle, écrit « plus de 460 millions ».

D'autres coûts s'ajoutent sans être imputés à l'incident lui-même. L'événement a obligé Knight à réexaminer la valeur de ses actifs : elle a déprécié 143 millions de dollars d'écarts d'acquisition et d'actifs incorporels. Le sauvetage du 6 août a coûté environ 40,5 millions de frais, si bien que les 400 millions levés n'ont rapporté que 359,5 millions nets. Au troisième trimestre 2012, la perte nette atteint 389,9 millions de dollars ; sur l'année, 347,1 millions, contre un bénéfice de 115,2 millions en 2011.

Mis en regard des capitaux propres, le choc est brutal. Les 440 millions annoncés le 2 août représentent environ 30 % des 1,46 milliard de capitaux propres de fin 2011, un calcul fait pour cette page qui rejoint l'estimation d'un analyste de JPMorgan citée par CNBC le 6 août 2012. L'amende de 12 millions de dollars infligée en 2013 pèse, elle, moins de 3 % de la perte : la sanction financière la plus lourde n'est pas venue du régulateur, mais des 45 minutes elles-mêmes.

Comment Knight a-t-elle survécu quelques jours, puis perdu son indépendance ?

La perte n'a pas seulement entamé le capital : elle a fait fuir les clients et les contreparties. Dans les comptes 2011 republiés le 6 août 2012, Knight explique avoir subi une baisse de ses flux d'ordres et des tensions de liquidité, et écrit qu'il existe un doute important sur sa capacité à poursuivre son activité. Son commissaire aux comptes, PricewaterhouseCoopers, ajoute ce même doute à son rapport. CNBC rapporte que la Bourse de New York a transféré temporairement à GETCO les responsabilités de teneur de marché de Knight sur plus de 500 titres.

Le sauvetage est bouclé le 6 août. Six sociétés, dont Jefferies, qui a conçu l'opération, achètent pour 400 millions de dollars d'actions privilégiées convertibles en actions ordinaires à 1,50 dollar, environ 267 millions d'actions. Faute de temps, le comité d'audit renonce au vote des actionnaires normalement requis, au motif que le délai aurait « gravement compromis » la viabilité financière de Knight, selon son communiqué du 6 août 2012. Les anciens actionnaires sont fortement dilués.

L'entreprise retrouve ensuite une partie de son activité. Le 17 octobre 2012, son directeur général, Thomas Joyce, affirme que sa part de marché dans les actions américaines a nettement remonté et que des mesures ont été prises pour renforcer les processus et les contrôles. Mais l'indépendance ne dure pas : le 19 décembre 2012, Knight et GETCO annoncent leur rapprochement. Les actionnaires de Knight peuvent choisir 3,75 dollars par action en numéraire ou des titres de la nouvelle société, une prime de 51 % sur le cours du 23 novembre 2012.

La fusion est réalisée le 1er juillet 2013 : Knight Capital Group et GETCO deviennent des filiales de KCG Holdings, et les anciens actionnaires de Knight reçoivent au total environ 720 millions de dollars en numéraire. Moins d'un an après l'incident, la société fondée en 1995 n'existe plus comme entreprise indépendante. Entre-temps, des actionnaires avaient engagé des actions de groupe, dont une dès le 17 août 2012, et la SEC avait ouvert son enquête formelle le 29 août 2012.

L'ordonnance du 16 octobre 2013 clôt le volet réglementaire. Knight Capital Americas y accepte, sans reconnaître ni contester les faits, un blâme, l'interdiction de commettre de nouvelles violations et une amende de 12 millions de dollars. Elle s'engage surtout à faire examiner par un consultant indépendant son cycle de développement logiciel pour tous ses systèmes critiques, ses procédures de déploiement de code, ses routeurs d'ordres, le lien automatique entre plafonds de capital et envoi d'ordres, et ses protocoles de réponse aux incidents. La liste dessine, en creux, tout ce qui manquait le 1er août.

Pourquoi une PME de Cotonou, d'Abidjan ou de Lyon est-elle concernée par un accident de Wall Street ?

Une PME ne route pas d'ordres de Bourse, mais elle met du code en production bien plus souvent qu'elle ne le croit : une mise à jour de la boutique en ligne, un nouveau module de paiement par mobile money, une application mobile publiée sur les magasins d'applications, une API qui relie le site à l'ERP, un scénario d'automatisation qui envoie des factures ou des relances WhatsApp. Chaque fois, il existe un moment où la nouvelle version remplace l'ancienne, et une question que personne ne pose : l'a-t-elle remplacée partout ?

Le « huitième serveur » prend dans une PME des formes très ordinaires. Une ancienne version de l'application mobile, restée sur les téléphones des clients, qui appelle encore une adresse d'API qu'on croyait abandonnée. Un deuxième serveur derrière un répartiteur de charge, oublié lors de la mise à jour. Une tâche planifiée sur une vieille machine. Une ancienne adresse de notification de paiement encore enregistrée chez l'opérateur. Un scénario d'automatisation dupliqué pour un test et jamais désactivé. Dans tous ces cas, le système fonctionne presque partout, et c'est précisément ce qui rend l'erreur invisible.

La vitesse joue le même rôle qu'à Wall Street, à une autre échelle. La SEC écrit dans son ordonnance qu'en l'absence de contrôles adaptés, la rapidité des systèmes automatisés peut transformer une erreur gérable en événement extrême. Une automatisation qui boucle peut envoyer des centaines de SMS facturés, un script de remboursement peut rembourser deux fois, un chatbot mal configuré peut répondre à tous les clients avec un prix erroné. Ce qui coûte, ce n'est pas l'erreur de départ, c'est le temps pendant lequel elle se répète sans que personne ne puisse l'arrêter.

Le risque grandit avec la facilité de produire du code. Les outils d'intelligence artificielle permettent aujourd'hui de générer une application ou une automatisation en quelques heures, ce que l'on appelle le vibe coding. Le code produit ainsi n'est ni meilleur ni pire qu'un autre, mais il arrive souvent en production sans relecture, sans tests et sans procédure de mise en ligne, avec des fonctions laissées « au cas où ». Les manquements décrits par la SEC chez Knight, absence de second regard, code inutilisé conservé, alertes non lues, se reproduisent alors à l'identique, chez des entreprises bien moins armées pour encaisser le choc.

Comment Richard SALANON aide-t-il une PME à mettre en production sans mauvaise surprise ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Knight Capital n'a jamais été son client : cette page raconte une histoire publique pour en tirer une méthode. Sur une application web sur mesure, Richard livre avec le code une procédure de mise en ligne écrite, un environnement de test distinct de la production et un numéro de version visible, pour que chacun puisse vérifier ce qui tourne réellement. Les fonctions abandonnées sont supprimées plutôt que cachées, et le retour vers la version précédente est préparé avant chaque mise en ligne, pas pendant la panne.

Les API et intégrations sont le terrain le plus exposé au « huitième serveur » : applications mobiles anciennes, adresses de notification de paiement, connecteurs vers un ERP ou WhatsApp. Richard commence par l'inventaire de tout ce qui appelle l'API, versionne les routes, journalise les échanges et pose des limites sur les volumes. Pour les projets menés en vibe coding, il relit et teste le code produit par l'IA avant toute mise en production et retire ce qui a servi aux essais.

Après la livraison, la maintenance et le support prennent le relais : mises à jour planifiées, sauvegardes vérifiées, surveillance des erreurs avec des alertes lues, et analyse de chaque incident pour corriger la cause, pas seulement le symptôme. Les accès administrateur, le code et la documentation restent à votre nom. Vous obtenez une réponse sous 24 heures. Le parcours de Richard est présenté sur la page Richard SALANON, et d'autres récits publics sont réunis dans les histoires.