Erreurs Excel en entreprise : les risques réels, cas documentés à l’appui

Une erreur dans un fichier Excel ne prévient pas : la cellule affiche un résultat plausible, le fichier circule, et la décision se prend sur un chiffre faux. Ce n’est pas un risque théorique. Les audits de classeurs réels montrent que la plupart des gros fichiers contiennent des erreurs, et plusieurs cas publics, d’une grande banque à une agence de santé, montrent ce qu’elles coûtent.

Voici ce que disent les études, quatre cas vérifiés à la source, les familles d’erreurs qu’ils révèlent et les mesures qui réduisent vraiment le risque. Le problème n’est pas Excel en soi : c’est l’usage d’un tableur, sans contrôle, pour des calculs qui engagent l’entreprise.

Ce que disent les études : la plupart des gros classeurs contiennent des erreurs

Raymond Panko, chercheur à l’université d’Hawaï, a compilé pendant des années les travaux sur les erreurs de tableur. Sa synthèse présentée à la conférence européenne EuSpRIG en 2000 (« Spreadsheet Errors: What We Know. What We Think We Can Do ») donne des ordres de grandeur toujours cités :

• Audits de classeurs réels : sur les 54 classeurs audités en 1997 et après, avec des méthodes plus rigoureuses que les premiers audits, 91 % contenaient des erreurs. La plupart de ces audits ne comptaient que les erreurs significatives.
• Taux d’erreur par cellule : dans trois grands classeurs examinés en profondeur, 1,1 %, 2,2 % et 2,5 % des cellules contenaient une erreur d’origine.
• Expériences en laboratoire : environ un millier de participants ont construit de petits classeurs, de 25 à 50 cellules, à partir d’énoncés dont la solution était connue. 51 % des classeurs contenaient au moins une erreur.
• Excès de confiance : dans une expérience, les participants estimaient en médiane à 10 % le risque d’avoir commis une erreur. 86 % en avaient commis une.

Ces audits datent de 1987 à 2000, et les classeurs ont changé depuis. L’explication de Panko, elle, n’a pas vieilli : dans les tâches intellectuelles complexes, le taux d’erreur humain tourne autour de 2 à 5 %, et une personne qui relit seule une feuille cellule par cellule ne trouve qu’environ la moitié des erreurs. Les relectures repèrent bien les fautes de frappe dans des formules courtes, beaucoup moins les erreurs de logique et les oublis. Un classeur de plusieurs centaines de formules a donc toutes les chances d’en contenir quelques-unes. La vraie question est de savoir lesquelles comptent.

JPMorgan, 2012 : un indicateur de risque calculé à coups de copier-coller

En 2012, le Chief Investment Office de JPMorgan Chase perd au moins 6,2 milliards de dollars sur un portefeuille de dérivés de crédit : c’est l’affaire dite de la « baleine de Londres ». Le rapport interne publié par la banque le 16 janvier 2013, repris en détail par le rapport du sous-comité d’enquête permanent du Sénat américain (mars 2013), décrit un nouveau modèle de mesure du risque, la VaR (valeur en risque), entré en service fin janvier 2012 et calculé dans des feuilles de calcul :

• l’équipe de validation des modèles avait noté que le calcul se faisait sur des feuilles de calcul, par un processus manuel, et qu’il était donc « sujet aux erreurs » ;
• les données étaient chargées à la main sans contrôle qualité suffisant, et les formules changeaient fréquemment ;
• l’automatisation prévue lors de la validation n’a jamais été réalisée.

Le rapport interne précise que le modèle fonctionnait avec une série de feuilles Excel « remplies manuellement, en copiant-collant des données d’une feuille à l’autre ». Il relève aussi une formule qui, après avoir soustrait l’ancien taux du nouveau, divisait par leur somme au lieu de diviser par leur moyenne, comme le prévoyait son concepteur (New Statesman, février 2013). Selon ce même rapport, cité par le Sénat, cette erreur a « probablement eu pour effet de réduire la volatilité d’un facteur deux et d’abaisser la VaR ». Toutes causes confondues, le nouveau modèle avait divisé par deux la VaR du portefeuille dès sa mise en place.

L’erreur de formule n’explique pas à elle seule les pertes : les deux rapports décrivent surtout des défaillances de gouvernance et de contrôle des risques. Mais elle illustre la situation la plus dangereuse : un tableur qui produit un indicateur de pilotage, rassurant et faux, que personne ne recalcule.

Public Health England, 2020 : 15 841 cas de Covid-19 restés hors des chiffres

Début octobre 2020, l’agence de santé publique anglaise découvre que 15 841 cas positifs, enregistrés entre le 25 septembre et le 2 octobre, n’ont pas été intégrés aux chiffres quotidiens (BBC, 5 octobre 2020). Les personnes testées avaient bien reçu leur résultat, mais la recherche de leurs contacts avait pris du retard.

La cause est détaillée dans un second article de la BBC :

• les laboratoires transmettaient leurs résultats sous forme de fichiers CSV, sans problème ;
• un traitement automatique les regroupait ensuite dans des modèles Excel au vieux format XLS, limité à environ 65 000 lignes, contre plus d’un million pour le format XLSX ;
• chaque test occupant plusieurs lignes, un modèle ne pouvait contenir qu’environ 1 400 cas. Au-delà, les cas suivants étaient simplement laissés de côté.

Aucune formule n’était fausse. Le fichier a atteint une limite, et rien ne l’a signalé. C’est la leçon la plus utile pour une PME : comparer le nombre de lignes reçues au nombre de lignes intégrées est exactement le genre de contrôle simple qui détecte une perte silencieuse. La limite actuelle d’une feuille, 1 048 576 lignes selon les spécifications d’Excel, est bien plus haute, mais elle existe toujours.

Reinhart et Rogoff, 2013 : cinq pays oubliés dans une moyenne

En 2010, les économistes Carmen Reinhart et Kenneth Rogoff publient « Growth in a Time of Debt » dans l’American Economic Review. Leur conclusion, une croissance qui chute nettement au-delà de 90 % de dette publique rapportée au PIB, est largement reprise dans le débat sur l’austérité.

Thomas Herndon, étudiant en économie à l’université du Massachusetts à Amherst, tente de reproduire ces résultats dans le cadre d’un exercice, sans y parvenir. Avec ses professeurs Michael Ash et Robert Pollin, il obtient le classeur de travail des auteurs et y trouve une erreur de plage : le calcul exclut entièrement cinq pays, l’Australie, l’Autriche, la Belgique, le Canada et le Danemark (Herndon, Ash et Pollin, 15 avril 2013). Une fois cette erreur corrigée, ainsi que d’autres choix qu’ils contestent (années de données exclues, pondération par pays), la croissance moyenne des pays au-delà de 90 % passe de -0,1 % à +2,2 % par an.

Nuance souvent oubliée : l’erreur de plage ne pèse qu’une partie de l’écart. Selon les auteurs de la critique, ce sont surtout l’exclusion de certaines années et la pondération qui l’expliquent. Reinhart et Rogoff ont reconnu l’erreur tout en maintenant le message central de leur travail (BBC, avril 2013). La leçon reste entière : l’erreur n’a été trouvée que parce que quelqu’un a eu accès au classeur et a tout recalculé.

Génétique : des noms de gènes transformés en dates

Saisissez SEPT2 ou MARCH1 dans une cellule : avec ses réglages par défaut, Excel les convertit en dates (« 2-Sep » et « 1-Mar » dans la version anglaise). Ce sont pourtant des symboles de gènes humains. En 2016, trois chercheurs ont passé au crible les fichiers Excel joints aux articles de 18 revues de génomique publiés entre 2005 et 2015 (Ziemann, Eren et El-Osta, Genome Biology, 2016). Sur 3 597 articles accompagnés de listes de gènes, 704 contenaient des noms convertis par erreur, soit 19,6 %. Le problème, signalé dès 2004, touche aussi des identifiants comme 2310009E13, convertis en nombre (2.31E+13).

Faute de pouvoir changer le logiciel de tout le monde, c’est la nomenclature qui a changé. Le comité international qui nomme les gènes humains (HGNC) a publié en 2020 de nouvelles règles : tous les symboles convertis automatiquement en dates par Excel ont été renommés, SEPT1 devenant SEPTIN1 et MARCH1 devenant MARCHF1 (Bruford et al., Nature Genetics, 2020). Selon la coordinatrice du comité, citée par The Verge, quelque 27 gènes avaient déjà été renommés pour cette raison au cours de l’année écoulée.

Excel pour Microsoft 365 et Excel 2024 permettent désormais de désactiver ces conversions automatiques ; sous Windows : Fichier, Options, Données, Conversion automatique des données. Sans cette option, la parade indiquée par Microsoft consiste à préformater les cellules en texte avant la saisie, ou à taper une apostrophe devant la valeur.

Les quatre familles d’erreurs à surveiller

Panko classe les erreurs de calcul en trois types : mécaniques (une faute de frappe, une mauvaise cellule désignée), de logique et d’omission. Pour choisir ses contrôles, une grille en quatre familles, tirée des cas ci-dessus, est plus pratique, car aucun contrôle ne les attrape toutes.

Un facteur aggrave les quatre : le travail manuel entre fichiers. Copier-coller des données d’un classeur à l’autre, envoyer des copies par e-mail, ressaisir un résultat ailleurs : chaque transfert est une occasion de se tromper, et une version de plus dont on ne sait pas si elle fait foi.

Réduire le risque sans changer d’outil

Pour la plupart des fichiers, une discipline simple suffit. Voici les mesures qui ont le meilleur rapport effort et effet :

• Séparer les saisies, les paramètres, les calculs et les résultats, idéalement sur des onglets distincts, sans aucune valeur tapée en dur dans une formule
• Encadrer chaque saisie avec la validation des données : liste de choix, valeurs minimale et maximale, format attendu
• Verrouiller les cellules de calcul, en sachant que la protection de feuille « n’est pas conçue comme une fonctionnalité de sécurité » : elle évite les accidents, pas les intentions
• Ajouter des contrôles visibles : totaux recoupés avec la source, nombre de lignes importées, écart signalé en couleur
• Faire relire les fichiers critiques par une autre personne que leur auteur, en suivant les antécédents des formules qui produisent les chiffres clés
• Traiter les identifiants (références, codes, numéros) comme du texte, et désactiver les conversions automatiques quand votre version d’Excel le permet
• Garder une seule version de référence dans un emplacement partagé, plutôt que des copies envoyées par e-mail
• Tester le fichier avec un cas dont le résultat est connu, à chaque modification

En 2000, la relecture cellule par cellule était le seul contrôle dont Panko jugeait l’efficacité démontrée, et un relecteur isolé laisse passer une erreur sur deux. Sur un fichier critique, deux relecteurs et des cas de test valent mieux qu’un auteur très sûr de lui.

Quand passer à un outil dédié

Ces mesures suffisent pour beaucoup de fichiers. Elles atteignent leurs limites quand :

• le fichier sert à décider, facturer, payer ou déclarer, et qu’une erreur coûte cher ;
• il est utilisé par des personnes qui ne l’ont pas construit et ne voient pas les formules ;
• le même calcul revient tous les jours, avec d’autres entrées ;
• plusieurs versions circulent et personne ne sait laquelle fait foi ;
• les données arrivent par import automatique, en volumes qui approchent les limites du fichier.

Dans ces situations, une application garde la même logique de calcul mais retire les occasions d’erreur : les formules ne sont plus modifiables, chaque saisie est contrôlée, et les résultats se vérifient automatiquement face à des cas de référence. C’est ce que j’ai fait chez mon employeur, en tirant de classeurs Excel complexes des mini-sites intranet locaux : les formules sont les mêmes, mais on ne saisit plus que ce que chaque écran demande. La méthode est décrite dans le guide transformer un fichier Excel en application web, et les signaux d’alerte dans 10 signes qu’il est temps de remplacer Excel.

Attention à ne pas déplacer le problème : une application reproduit fidèlement les erreurs d’un classeur si l’on recopie ses formules sans les vérifier. Les pièges propres au passage d’Excel au code, comme les arrondis, les dates et les décimales, sont détaillés dans recréer des formules Excel en JavaScript.

En résumé : le risque vient de l’absence de contrôle

Les erreurs de tableur sont normales : les audits en trouvent dans la grande majorité des gros classeurs, et leurs auteurs les sous-estiment. Les cas de JPMorgan, de Public Health England, de Reinhart et Rogoff et des noms de gènes ont un point commun : le résultat n’était ni recalculé ni contrôlé de façon indépendante avant de servir. Commencez par vos trois fichiers les plus critiques : séparez saisies et calculs, ajoutez des totaux de contrôle, faites-les relire. Si l’un d’eux reste trop exposé, c’est le moment d’en faire un outil dédié, ce que je propose avec l’accompagnement Excel en application web.