- Walid Hamrouni
- août 2, 2017
Les 5 plus gros échecs de projets informatique
Aujourd’hui l’informatique et la technologie font partie intégrante de notre quotidien. Ces outils sont devenus indispensables afin d’accomplir nos tâches quotidiennes, et rares sont les jobs de nos jours où la technologie n’intervient pas.
Néanmoins, ces derniers peuvent parfois avoir quelques ratés, entraînant de douloureux et coûteux échecs. Dans cet article nous allons nous pencher sur 5 des plus gros échecs de projets informatique :
Table des matières
1. Une équipe professionnelle de basket ball allemand est reléguée en division inférieure en raison d’une mise à jour Windows
Le 13 Mars 2015, Paderborn Baskets, une équipe de deuxième division allemande de basket ball, est reléguée en division inférieure à cause du démarrage tardif du match qui l’oppose aux Chemnitz Niners.
En effet, celui-ci s’est vu retardé car l’ordinateur branché au tableau d’affichage a dû effectuer une mise à jour de 17 minutes avant de démarrer.
Le match devait commencer normalement, lorsque l’équipe de Paderborn connecte son ordinateur au tableau d’affichage. “L’ordinateur a été connecté normalement vers 18h00” déclare le manager général de Paderborn Patrick Siedel, soit 1h30 avant le début de la rencontre.
Néanmoins, d’après Siedel “Durant l’échauffement des deux équipes, l’ordinateur a planté. Nous avons réussi à le redémarrer vers 19h20, mais il s’est mis à télécharger plusieurs mises à jour automatiques”.
Lorsque l’ordinateur eut fini de télécharger et d’installer toutes les mises à jour, le match a finalement commencé à 19h55.
Paderborn remporta le match 69 à 62. Cependant, Chemnitz déposa une réclamation contre la victoire à cause des 25 minutes de retard prises par Paderborn.
Les règles de basket-ball en Allemagne ne permettant qu’un délai de 15 minutes, Paderborn devrait donc être pénalisé selon eux. “Vous ne pouvez pas blâmer Chemnitz”, a ajouté Seidel.
En conséquence de quoi, Paderborn s’est vu retirer un point de pénalité et s’est retrouvé relégué de la division ProA à la division ProB.
2. Un grand distributeur pharmaceutique échoue la mise en oeuvre de son ERP
Au début des années 90, FoxMeyer une entreprise dans le domaine de la santé, était le 5ème plus grand distributeur pharmaceutique aux USA, avec un chiffre d’affaires de 5 milliards de dollars et quelques 500 000 produits distribués quotidiennement.
La compétition féroce dans l’industrie poussa FoxMeyer à trouver une solution qui lui permettrait de prendre des décisions de logistique complexe tout en faisant face aux différentes problématiques de coût.
C’est ainsi que l’entreprise texane décida de mettre en place un ERP offrant selon eux le meilleur moyen d’unifier l’accès à une information en temps réel, l’automatisation et l’intégration de leur système d’inventaire à l’aide d’un seul logiciel.
Celle-ci espérait ainsi éliminer toutes les activités superficielles et redondantes, avoir un meilleur contrôle de leur inventaire, mais également d’être plus efficace dans la gestion de sa relation client.
La mise en place de ce projet de plusieurs millions de dollars, était le premier du genre dans l’industrie pharmaceutique.
L’implémentation de SAP R/3 aura coûté à FoxMeyer 65 millions de dollars alors que l’entreprise espérait pouvoir faire à l’aide de cet ERP 40 millions de dollars d’économie par an.
Le budget inclus:
- 4,8 millions de dollars pour la mise en place des serveurs par HP
- 4 millions de dollars pour le logiciel SAP R/3
- Plusieurs millions de dollars de frais de consulting
- 18 millions de dollars pour la mise en place d’un entrepôt totalement automatisé
Suite à l’échec de ce projet, une mauvaise organisation du projet dès la phase de cahier des charges jusqu’au aux étapes d’implémentations a été mise en avant.
Planification:
- Choix d’un ERP non compatible avec l’activité de FoxMeyer
- Le mauvais choix de FoxMeyer de ne pas avoir écouté l’avis d’autres consultants et d’avoir basé son choix sur la réputation d’Andersen Consulting et de SAP
- Ne pas avoir mis en place un plan d’urgence
- Le manque d’implication des utilisateurs durant le processus de planification
Implémentation:
- Aucune restructuration du processus opérationnel
- Phase de test bâclée
- Une portée du projet beaucoup trop ambitieuse
- Projet beaucoup tourné vers les intérêts des collaborateurs IT
- Mauvais management et peu de support
- Manque de coopération de la part des utilisateurs
Malheureusement pour FoxMeyer, cet ambitieux projet a fini en gouffre financier avec un total de 100 millions de dollars investis (comprenant les 60 millions de budget initial et 40 millions de frais supplémentaires afin de tenter de sauver le projet) dans la mise en oeuvre de l’ERP.
FoxMeyer, en raison des nombreuses difficultés et retards n’a réussi à réaliser que la moitié des économies projetée, provoquant la liquidation de la société.
Livre Blanc
Parler d’expérience collaborateur, c’est l’assurance de pouvoir rédiger pour être dans
l’air du temps et dans lequel on trouvera à peu près tout ce qu’on veut.
3. Un système de contrôle aérien de 2 milliards de dollars plante à cause d’un manque de mémoire
Le 30 Avril 2014, plusieurs centaines de vol ont été retardés ou annulés à l’aéroport LAX de Los Angeles, à cause d’une panne généralisée de tous ses ordinateurs. En effet ces derniers ont tous été victimes d’un bug de l’ERAM, le logiciel de contrôle du trafic aérien.
L’erreur du système a pour cause un vol de contrôle d’un avion espion U-2 dans le ciel de la région. Le logiciel produit par Lockheed Martin et qui a coûté environ 2,4 milliards de dollars s’est mis en boucle infinie afin d’essayer de corriger ce qu’il considérait comme une erreur de navigation.
En effet, le logiciel était incapable de trouver l’altitude de l’avion dans le plan de vol de celui-ci.
Un contrôleur aérien tenta de réparer le problème manuellement en entrant une estimation de l’altitude (environ 60,000 pieds), poussant ainsi le logiciel à calculer toutes les trajectoires possibles de ce dernier afin de vérifier qu’il n’était pas dans une trajectoire pouvant entraîner un accident avec d’autres avions volant à plus basse altitude.
Ce processus a fini par consommer toute la mémoire restante et a entraîné l’arrêt de toutes les autres fonctions du système. Fort heureusement, aucun accident n’est à déplorer malgré la panne.
Le système ERAM à planté car il limite délibérément le nombre de données que chaque avion peut lui envoyer.
En effet, la plupart des avions ont des plans de vol plutôt simple et donc ne dépassent jamais la limite du système. Le plan de vol du U-2, en revanche, étant plus complexe, a fini par pousser le système jusqu’à ses limites entraînant ainsi la panne.
à travers nos solutions de
communication interne
4. Le fiasco de la mise en place du nouveau système de gestion de la paie de Queensland Health
Lorsque le gouvernement de l’état de Queensland (Australie) a annoncé la mise en place d’un nouveau système de gestion de la paie en 2006, le projet semblait plutôt simple à mettre en place.
Pourtant, 5 ans plus tard, la commission en charge d’évaluer les manquements qualifia ce projet “de plus gros échec de l’administration publique australienne de l’histoire”.
Fin 2007, l’Etat du Queensland choisit IBM Australie comme contractant pour développer et mettre en place le nouveau système de paiement de Queensland Health (QH), une agence publique de santé employant 80,000 salariés.
Le contrat initial prévoyait un budget de 6 millions de dollars et une mise en place du nouveau système au bout de 6 mois.
Malheureusement pour les parties prenantes, le déroulement du projet fut parsemé d’embûches. En effet, le système ne fut mis en place que vers fin 2010, accumulant donc un retard de presque 2 ans et demi?e plus, le système passa en production avec des défauts majeurs, et un coût de développement supplémentaire de presque 25 millions de dollars.
Même si le système pouvait s’acquitter plus ou moins correctement de certaines fonctions de base, QH dut investir dans un recrutement massif afin de prendre en charge l’activité manuelle du traitement de la paie, ajoutant ainsi à la facture 1.15 milliards de dollars sur 8 années.
Le rapport de la commission en charge du dossier à mis en lumière de nombreux manquements à tous les niveau du projets: de l’approvisionnement, la planification des dates de livraisons mais également la gestion du projet par IBM.
5. Le lancement d’Ariane 5 ou l’un des bug les plus coûteux de l’histoire
Le vol 501 de la fusée Ariane 5 fait partie du projet Ariane, programme aérospatial européen ayant pour but d’envoyer 2 satellites de 3 tonnes en orbite et de consolider la place des européens dans le domaine aérospatial.
Ce projet à mis 10 ans à être réalisé pour un coût total de 7 milliards de dollars.Le 4 juin 1996, la fusée Ariane 5 fût lancée avant d’exploser en plein vol quelques secondes après. Les deux système de guidage inertiel ou Inertial Reference Systems (IRS) en anglais, possédaient le même hardware mais également le même logiciel et fonctionnaient en parallèle.
En effet, si l’ordinateur de bord détecte une panne du système actif, il bascule automatiquement sur le système de secours.
L’IRS possède son propre ordinateur interne, lui permettant de mesurer l’altitude et le déplacement dans l’espace de la fusée. Ces informations étaient envoyées par le système vers l’ordinateur de bord de la fusée qui lui exécutait le programme de vol.
Le système de lancement actif s’éteignit au bout de 36.7 secondes, après le départ de la fusée lorsque son ordinateur interne tenta de convertir les données de rotation et de vitesse d’un format 64-bit vers un format 16-bit.
En effet, l’accélération de la fusée était beaucoup trop grande provoquant un dépassement d’entier dans le calculateur et créant ainsi une erreur.
Le calculateur tentait de convertir un nombre supérieur à 32,767 le dernier entier stockable dans une mémoire 16-bit.
De plus, le système interne de l’IRS ne possédait pas de capacité à gérer les exceptions entraînant donc l’arrêt de ce dernier.
En réalité, la cause principale de cet échec vient du fait que le système de secours étant exactement le même que le système actif, il fut lui aussi victime de la même erreur.
Pourtant, le système en cause n’avait plus aucun rôle à jouer après le décollage de la fusée car sa fonction principale est d’aligner le système avant le lancement. Ce dernier aurait donc dû être éteint.
Cependant, les ingénieurs (également présent lors des vols d’Ariane précédents) avaient préféré garder le système ouvert pendant les 40 premières secondes du vol, afin de faciliter un redémarrage dans le cas où le système “compte à rebours” connaitrait un court arrêt.
C’est ainsi que la fusée finit par exploser en plein vol, entraînant un coût de 370 millions de dollars supplémentaires et transformant un projet novateur en poussière.
avec eXo Platform
Articles associés
- Tous
- eXo
- Digital workplace
- Engagement collaborateur
- Open source
- Avenir du travail
- Actualités
- Collaboration
- Expérience collaborateur
- intranet
- Communication interne
- onboarding
- Gestion des connaissances
- Conduite de changement
- Leadership
- Cartoon
- Astuces et bonnes pratiques
- Etudes de cas
- Guide
- Infographie
- Productivité
- Télétravail
- Transformation digitale
- Tutoriel
- Actualités produit
- Reconnaissance des employés
- Tendances
