Avez-vous entendu parler de l’entrepôt qui disparaît? Un jour, il a disparu — non pas de la vue physique, mais des yeux vigilants du système de distribution automatisé d’un détaillant bien connu. Un problème logiciel avait en quelque sorte effacé l’existence de l’entrepôt, de sorte que les marchandises destinées à l’entrepôt étaient redirigées ailleurs, tandis que les marchandises de l’entrepôt languissaient. Parce que l’entreprise était en difficulté financière et avait fermé d’autres entrepôts pour économiser de l’argent, les employés de l’entrepôt « manquant » se sont tus. Pendant trois ans, rien n’est arrivé ni parti. Cependant, les employés recevaient toujours leurs chèques de paie, car un système informatique différent gérait la paie. Lorsque le problème du logiciel est finalement apparu, la marchandise dans l’entrepôt a été vendue et la haute direction a dit aux employés de ne rien dire de l’épisode.
Cette histoire flotte dans l’industrie des technologies de l’information depuis 20 – quelques années. C’est probablement apocryphe, mais pour ceux d’entre nous dans l’entreprise, c’est tout à fait plausible. Pourquoi? Parce que des épisodes comme celui-ci arrivent tout le temps. En octobre dernier, par exemple, le géant de l’alimentation britannique J Sainsbury PLC a dû annuler son investissement de 526 millions de dollars américains dans un système automatisé de gestion de la chaîne d’approvisionnement. Il semble que la marchandise était coincée dans les dépôts et entrepôts de l’entreprise et ne parvenait pas à bon nombre de ses magasins. Sainsbury a été obligé d’embaucher environ 3000 commis supplémentaires pour stocker ses étagères manuellement.
Ce n’est que l’un des derniers d’une longue et lugubre histoire de projets informatiques qui ont mal tourné. La plupart des experts en informatique conviennent que de telles défaillances se produisent beaucoup plus souvent qu’elles ne le devraient. De plus, les échecs sont universellement sans préjugés: ils se produisent dans tous les pays; dans les grandes entreprises et les petites; dans les organisations commerciales, à but non lucratif et gouvernementales; et sans égard au statut ou à la réputation. Les coûts commerciaux et sociétaux de ces échecs — en termes de dollars gaspillés par les contribuables et les actionnaires ainsi que d’investissements impossibles à réaliser — se chiffrent maintenant en milliards de dollars par an.
Le problème ne fait qu’empirer à mesure qu’IL devient omniprésent. Cette année, les organisations et les gouvernements dépenseront environ 1 billion de dollars en matériel informatique, logiciels et services dans le monde entier. Parmi les projets informatiques lancés, de 5 à 15% seront abandonnés avant ou peu de temps après la livraison car désespérément inadéquats. Beaucoup d’autres arriveront en retard et au-dessus du budget ou nécessiteront un remaniement massif. Peu de projets informatiques, en d’autres termes, réussissent vraiment.
La plus grande tragédie est que les défaillances logicielles sont pour la plupart prévisibles et évitables. Malheureusement, la plupart des organisations ne considèrent pas la prévention de l’échec comme une question urgente, même si cette vision risque de nuire à l’organisation et peut-être même de la détruire. Comprendre pourquoi cette attitude persiste n’est pas seulement un exercice académique; cela a d’énormes implications pour les entreprises et la société.
LE LOGICIEL EST PARTOUT. C’est ce qui nous permet d’obtenir de l’argent à un guichet automatique, de passer un appel téléphonique et de conduire nos voitures. Un téléphone portable typique contient maintenant 2 millions de lignes de code logiciel; d’ici 2010, il en aura probablement 10 fois plus. General Motors Corp. estime que d’ici là, ses voitures auront chacune 100 millions de lignes de code.
Une entreprise moyenne consacre environ 4 à 5 % de son chiffre d’affaires aux technologies de l’information, tandis que celles qui dépendent fortement de l’informatique — comme les sociétés financières et de télécommunications — y consacrent plus de 10 %. En d’autres termes, c’est maintenant l’une des dépenses les plus importantes de l’entreprise en dehors des coûts des employés. Une grande partie de cet argent est consacrée aux mises à niveau matérielles et logicielles, aux frais de licence de logiciel, etc., mais une grande partie est consacrée à de nouveaux projets logiciels destinés à créer un avenir meilleur pour l’organisation et ses clients.
Les gouvernements, eux aussi, sont de grands consommateurs de logiciels. En 2003, le Royaume-Uni avait plus de 100 grands projets informatiques gouvernementaux en cours pour un montant total de 20,3 milliards de dollars. En 2004, le gouvernement américain a répertorié 1200 projets informatiques civils coûtant plus de 60 milliards de dollars, plus 16 milliards de dollars supplémentaires pour les logiciels militaires.
N’importe lequel de ces projets peut coûter plus de 1 milliard de dollars. Pour prendre deux exemples actuels, l’effort de modernisation informatique du département des Anciens combattants des États-Unis devrait s’élever à 3,5 milliards de dollars, tandis que l’automatisation des dossiers de santé du National Health Service du Royaume-Uni devrait coûter plus de 14,3 milliards de dollars pour le développement et 50,8 milliards de dollars pour le déploiement.
De tels projets de mégasoftware, autrefois rares, sont maintenant beaucoup plus courants, car de plus petites opérations informatiques sont regroupées en « systèmes de systèmes ». »Le contrôle du trafic aérien en est un excellent exemple, car il repose sur des connexions entre des dizaines de réseaux qui fournissent des communications, des données météorologiques, de navigation et d’autres données. Mais l’astuce de l’intégration a empêché de nombreux développeurs informatiques, au point où les chercheurs universitaires croient de plus en plus que l’informatique elle-même pourrait devoir être repensée à la lumière de ces systèmes extrêmement complexes.
Lorsqu’un projet échoue, il met en péril les perspectives d’une organisation. Si l’échec est suffisamment important, il peut voler tout l’avenir de l’entreprise. Dans une crise stellaire, un système de planification des ressources mal mis en œuvre a conduit FoxMeyer Drug Co., une société de distribution de médicaments en gros de 5 milliards de dollars à Carrollton, au Texas, a sombré dans la faillite en 1996.
Une défaillance informatique au sein du gouvernement peut mettre en péril la sécurité nationale, comme l’a montré la débâcle du dossier virtuel du FBI. Le système VCF de 170 millions de dollars, une base de données consultable destinée à permettre aux agents de « relier les points » et de suivre des éléments de renseignement disparates, a pris fin il y a cinq mois sans qu’aucun système ne soit déployé.
Les défaillances informatiques peuvent également freiner la croissance économique et la qualité de vie. En 1981, la Federal Aviation Administration des États-Unis a commencé à étudier la mise à niveau de son système de contrôle du trafic aérien désuet, mais les efforts pour en construire un de remplacement ont rapidement été criblés de problèmes. En 1994, lorsque l’agence a finalement renoncé au projet, le coût prévu avait triplé, plus de 2,6 milliards de dollars avaient été dépensés et la date de livraison prévue avait reculé de plusieurs années. Chaque passager d’avion qui est retardé à cause de Skyways bloqués ressent toujours cette annulation; l’impact économique cumulé de tous ces retards sur les compagnies aériennes américaines (peu importe les passagers) approche les 50 milliards de dollars.
Dans le monde entier, il est difficile de dire combien de projets logiciels échouent ou combien d’argent est gaspillé en conséquence. Si vous définissez l’échec comme l’abandon total d’un projet avant ou peu de temps après sa livraison, et si vous acceptez un taux d’échec prudent de 5%, des milliards de dollars sont gaspillés chaque année sur de mauvais logiciels.
Par exemple, en 2004, les États-Unis. le gouvernement a dépensé 60 milliards de dollars en logiciels (sans compter les logiciels intégrés dans les systèmes d’armes); un taux d’échec de 5% signifie que 3 milliards de dollars ont probablement été gaspillés. Cependant, après plusieurs décennies en tant que consultant en informatique, je suis convaincu que le taux d’échec est de 15 à 20% pour les projets dont le budget est de 10 millions de dollars ou plus. En examinant l’investissement total dans de nouveaux projets logiciels — gouvernementaux et d’entreprises — au cours des cinq dernières années, j’estime que les échecs de projets ont probablement coûté à l’économie américaine au moins 25 milliards de dollars et peut-être jusqu’à 75 milliards de dollars.
Bien sûr, ces 75 milliards de dollars ne reflètent pas les projets qui dépassent leurs budgets — ce que la plupart des projets font. Il ne reflète pas non plus les projets livrés tardivement — ce que la majorité d’entre eux sont. Il ne tient pas compte non plus des coûts d’opportunité de devoir recommencer une fois un projet abandonné ou des coûts de systèmes truffés de bogues qui doivent être retravaillés à plusieurs reprises.
Ensuite, il y a aussi le coût des litiges des clients furieux qui poursuivent les fournisseurs pour des systèmes mal mis en œuvre. Lorsque vous additionnez tous ces coûts supplémentaires, l’onglet annuel pour les logiciels défaillants et en difficulté varie de 60 à 70 milliards de dollars rien qu’aux États-Unis. Pour cet argent, vous pourriez lancer la navette spatiale 100 fois, construire et déployer l’ensemble du Système de positionnement mondial à 24 satellites, et développer le Boeing 777 à partir de zéro – et il vous reste encore quelques milliards.
Pourquoi les projets échouent-ils si souvent ?
Parmi les facteurs les plus courants:
- Objectifs du projet irréalistes ou non articulés
- Estimations inexactes des ressources nécessaires
- Exigences système mal définies
- Mauvais reporting de l’état du projet
- Risques non gérés
- Mauvaise communication entre les clients, les développeurs et les utilisateurs
- Utilisation d’une technologie immature
- Incapacité à gérer la complexité du projet
- Pratiques de développement bâclées
- Mauvaise gestion du projet
- Politique des parties prenantes
- Pressions commerciales
Bien sûr, les projets informatiques sont rarement réalisés échouez pour une ou deux raisons seulement. Le projet VCF du FBI souffrait de nombreux problèmes énumérés ci-dessus. La plupart des échecs, en fait, peuvent être attribués à une combinaison de décisions techniques, de gestion de projet et d’affaires. Chaque dimension interagit avec les autres de manière compliquée qui exacerbe les risques et les problèmes du projet et augmente la probabilité d’échec.
Considérez une simple corvée logicielle: un système d’achat qui automatise la commande, la facturation et l’expédition des pièces, afin qu’un vendeur puisse saisir la commande d’un client, la faire vérifier automatiquement par rapport aux exigences de prix et de contrat, et organiser l’envoi des pièces et de la facture au client depuis l’entrepôt.
Les exigences du système spécifient quatre étapes de base. Tout d’abord, il y a le processus de vente, qui crée un acte de vente. Cette facture est ensuite envoyée dans le cadre d’une procédure judiciaire, qui examine les conditions contractuelles de la vente potentielle et les approuve. En troisième ligne, le processus de fourniture, qui envoie les pièces sous contrat, suivi du processus de financement, qui envoie une facture.
Disons que le premier processus, pour les ventes, est en cours d’écriture, les programmeurs traitent chaque commande comme si elle avait été passée sur le site principal de l’entreprise, même si l’entreprise a des succursales dans plusieurs États et pays. Cette erreur, à son tour, affecte la façon dont la taxe est calculée, le type de contrat émis, etc.
Plus tôt l’omission est détectée et corrigée, mieux c’est. C’est un peu comme tricoter un pull. Si vous repérez un point manqué juste après l’avoir fait, vous pouvez simplement démêler un peu de fil et passer à autre chose. Mais si vous n’attrapez pas l’erreur jusqu’à la fin, vous devrez peut-être démêler tout le pull juste pour refaire ce point.
Si les codeurs logiciels ne détectent pas leur omission avant les tests finaux du système — ou pire, jusqu’à ce que le système ait été déployé – les coûts encourus pour corriger l’erreur seront probablement plusieurs fois plus élevés que s’ils avaient attrapé l’erreur alors qu’ils travaillaient encore sur le processus de vente initial.
Et contrairement à un point manqué dans un pull, ce problème est beaucoup plus difficile à identifier; les programmeurs verront seulement que des erreurs apparaissent, et celles-ci peuvent avoir plusieurs causes. Même après la correction de l’erreur d’origine, ils devront modifier d’autres calculs et la documentation, puis retester chaque étape.
En fait, des études ont montré que les spécialistes des logiciels consacrent environ 40 à 50% de leur temps à des reprises évitables plutôt qu’à ce qu’ils appellent un travail à valeur ajoutée, qui est essentiellement un travail bien fait la première fois. Une fois qu’un logiciel arrive sur le terrain, le coût de la correction d’une erreur peut être 100 fois plus élevé qu’il ne l’aurait été pendant la phase de développement.
Si les erreurs abondent, la reprise peut commencer à submerger un projet, comme un dériveur dans une tempête. Pire encore, les tentatives de correction d’une erreur en introduisent souvent de nouvelles. C’est comme si tu renflouais ce canot, mais tu créais aussi des fuites. Si trop d’erreurs sont produites, le coût et le temps nécessaires pour terminer le système deviennent si importants que cela n’a aucun sens.
Dans les termes les plus simples, un projet informatique échoue généralement lorsque la reprise dépasse le travail à valeur ajoutée prévu au budget. C’est ce qui est arrivé à Sydney Water Corp., le plus grand fournisseur d’eau en Australie, lorsqu’elle a tenté d’introduire un système automatisé d’information et de facturation des clients en 2002. Selon une enquête du Vérificateur général australien, parmi les facteurs qui ont condamné le projet, il y avait une planification et des spécifications inadéquates, ce qui a entraîné de nombreuses demandes de changement et des coûts et des retards supplémentaires importants. Sydney Water a abandonné le projet à mi-chemin, après avoir dépensé 61 millions de dollars australiens (33,2 millions de dollars américains).
Tout cela nous amène à la question évidente: pourquoi tant d’erreurs se produisent-elles?
Les échecs de projets logiciels ont beaucoup en commun avec les accidents d’avion. Tout comme les pilotes n’ont jamais l’intention de s’écraser, les développeurs de logiciels ne visent pas à échouer. Lorsqu’un avion commercial s’écrase, les enquêteurs examinent de nombreux facteurs, tels que la météo, les dossiers de maintenance, la disposition et la formation du pilote et les facteurs culturels au sein de la compagnie aérienne. De même, nous devons examiner l’environnement commercial, la gestion technique, la gestion de projet et la culture organisationnelle pour aller aux racines des défaillances logicielles.
La concurrence et la nécessité de réduire les coûts sont les principaux facteurs économiques. De plus en plus, les cadres supérieurs s’attendent à ce que les services informatiques fassent plus avec moins et le fassent plus rapidement qu’auparavant; ils considèrent les projets logiciels non pas comme des investissements, mais comme des coûts purs qui doivent être contrôlés.
Les exigences politiques peuvent également nuire au calendrier, au coût et à la qualité d’un projet informatique. Lorsque l’aéroport international de Denver a tenté de déployer son système automatisé de manutention des bagages, les dirigeants politiques de l’État et locaux ont maintenu le projet selon un calendrier irréaliste après l’autre. L’échec de la livraison du système à temps a retardé l’ouverture de l’aéroport en 1995 (alors le plus grand des États-Unis), ce qui a aggravé l’impact financier.
Même après l’achèvement du système, il n’a jamais fonctionné de manière fiable: il a mâché les bagages et les chariots utilisés pour faire la navette entre les bagages ont fréquemment déraillé. Finalement, United Airlines, le principal locataire de l’aéroport, a poursuivi l’entrepreneur du système, et l’épisode est devenu un témoignage des dangers de l’opportunité politique.
Un manque de soutien de la haute direction peut également nuire à une entreprise informatique. Cela va de l’incapacité à allouer suffisamment d’argent et de main-d’œuvre au fait de ne pas établir clairement la relation du projet informatique avec les activités de l’organisation. En 2000, le détaillant Kmart Corp., à Troy, au Michigan., a lancé un11.4 milliards d’efforts de modernisation informatique visant à relier ses systèmes de vente, de marketing, d’approvisionnement et de logistique, afin de mieux rivaliser avec son rival Wal-Mart Corp., à Bentonville, en Arkansas. Wal-Mart s’est cependant avéré trop formidable et, 18 mois plus tard, Kmart, à court de liquidités, a réduit sa modernisation, annulant les 130 millions de dollars qu’il y avait déjà investis. Quatre mois plus tard, elle a déclaré faillite; l’entreprise continue de lutter aujourd’hui.
Souvent, les gestionnaires de projets informatiques désireux de se faire financer recourent à une forme de poker menteur, surpromisant ce que leur projet fera, combien il en coûtera et quand il sera terminé. De nombreux projets logiciels, sinon la plupart, commencent avec des budgets trop faibles. Lorsque cela se produit, les développeurs doivent compenser le manque à gagner d’une manière ou d’une autre, généralement en essayant d’augmenter la productivité, en réduisant la portée de l’effort ou en prenant des raccourcis risqués lors des phases de révision et de test. Tout cela augmente la probabilité d’erreur et, en fin de compte, d’échec.
Un système de réservation de voyage à la fine pointe de la technologie piloté par un consortium de Budget Rent-A-Car, Hilton Hotels, Marriott et AMR, la société mère d’American Airlines, en est un exemple. En 1992, après trois ans et demi et 165 millions de dollars, le groupe abandonne le projet, invoquant deux raisons principales : un calendrier de développement trop optimiste et une sous-estimation des difficultés techniques en jeu. C’est le même groupe qui avait déjà construit le système de réservation Sabre à succès, prouvant que les performances passées ne garantissent pas les résultats futurs.
Après que les enquêteurs de l’accident ont considéré la météo comme un facteur dans un accident d’avion, ils examinent l’avion lui-même. Y a-t-il quelque chose dans la conception de l’avion qui a causé le crash? Portait-il trop de poids?
Dans les échecs de projets informatiques, des questions similaires se posent invariablement concernant les composants techniques du projet: le matériel et les logiciels utilisés pour développer le système et les pratiques de développement elles-mêmes. Les organisations sont souvent séduites par le chant des sirènes de l’impératif technologique — l’envie incontrôlable d’utiliser les dernières technologies dans l’espoir de gagner un avantage concurrentiel. Avec l’évolution rapide de la technologie et la promesse de nouvelles capacités fantastiques, il est facile de succomber. Mais l’utilisation d’une technologie immature ou non testée est une voie sûre vers l’échec.
En 1997, après avoir dépensé 40 millions de dollars, l’État de Washington a mis fin à un projet informatique qui aurait traité les permis de conduire et les immatriculations de véhicules. Les responsables des véhicules à moteur ont admis qu’ils étaient pris dans la poursuite de la technologie au lieu de se concentrer sur la mise en œuvre d’un système répondant à leurs exigences. La débâcle informatique qui a fait tomber le médicament FoxMeyer un an plus tôt a également découlé de l’adoption d’un système de planification des ressources à la pointe de la technologie, puis de l’avoir poussé au-delà de ce qu’il pouvait faire.
La taille d’un projet est une source d’échec. Des études indiquent que les projets à grande échelle échouent trois à cinq fois plus souvent que les petits. Plus le projet est vaste, plus il y a de complexité à la fois dans ses éléments statiques (les éléments discrets du logiciel, du matériel, etc.) et ses éléments dynamiques (les couplages et les interactions entre le matériel, le logiciel et les utilisateurs; les connexions à d’autres systèmes, etc.). Une plus grande complexité augmente la possibilité d’erreurs, car personne ne comprend vraiment toutes les parties en interaction du tout ou n’a la capacité de les tester.
Cela donne à réfléchir mais c’est vrai: il est impossible de tester en profondeur un système informatique de toute taille réelle. Roger L. Pressman a souligné dans son livre Software Engineering, l’un des textes classiques dans le domaine, que « des tests exhaustifs posent certains problèmes logistiques….Même un petit programme de 100 lignes avec des chemins imbriqués et une seule boucle s’exécutant moins de vingt fois peut nécessiter l’exécution de 10 à la puissance de 14 chemins possibles. »Tester tous ces chemins de 100 billions, a-t-il noté, en supposant que chacun pourrait être évalué en une milliseconde, prendrait des années 3170.
Tous les systèmes informatiques sont intrinsèquement fragiles. Dans un grand bâtiment en briques, vous devrez retirer des centaines de briques stratégiquement placées pour faire s’effondrer un mur. Mais dans un logiciel de 100 000 lignes, il suffit d’une ou deux mauvaises lignes pour produire des problèmes majeurs. En 1991, une partie du réseau téléphonique d’ATandamp;T s’est éteinte, laissant 12 millions d’abonnés sans service, tout cela à cause d’un seul caractère mal typé dans une ligne de code.
Les pratiques de développement bâclées sont une riche source d’échec et peuvent provoquer des erreurs à n’importe quelle étape d’un projet informatique. Pour aider les organisations à évaluer leurs pratiques de développement de logiciels, les États-Unis. Le Software Engineering Institute, à Pittsburgh, a créé le modèle de maturité des capacités, ou CMM. Il évalue les pratiques d’une entreprise par rapport à cinq niveaux de maturité croissante. Le niveau 1 signifie que l’organisation utilise des pratiques de développement ad hoc et éventuellement chaotiques. Le niveau 3 signifie que l’entreprise a caractérisé ses pratiques et les comprend maintenant. Le niveau 5 signifie que l’organisation comprend quantitativement les variations des processus et des pratiques qu’elle applique.
En janvier, près de 2000 organisations gouvernementales et commerciales avaient déclaré volontairement des concentrations de MMT. Plus de la moitié ont reconnu être au niveau 1 ou 2, 30 % étaient au niveau 3 et seulement 17 % avaient atteint le niveau 4 ou 5. Les pourcentages sont encore plus lamentables lorsque vous réalisez qu’il s’agit d’un groupe auto-sélectionné; évidemment, les entreprises ayant les pires pratiques informatiques ne se soumettront pas à une évaluation du CMM. (Le CMM est remplacé par le CMM-Intégration, qui vise à une évaluation plus large de la capacité d’une organisation à créer des systèmes à forte intensité logicielle.)
Les pratiques informatiques immatures ont condamné les États-Unis. L’effort de modernisation de 4 milliards de dollars de l’Internal Revenue Service en 1997, et ils ont continué de nuire à la modernisation actuelle de 8 milliards de dollars de l’IRS. Il peut être intrinsèquement impossible de traduire le code fiscal en code logiciel — le droit fiscal est complexe et repose sur une législation souvent vague, et il change tout le temps. Du point de vue d’un développeur informatique, c’est un cauchemar pour les exigences. Mais l’IRS n’a pas été aidé par l’hostilité ouverte entre les programmeurs internes et externes, une sous-estimation risible du travail impliqué et de nombreuses autres mauvaises pratiques.
LES ACTIONS DU PILOTE JUSTE AVANT qu’un avion ne s’écrase sont toujours d’un grand intérêt pour les enquêteurs. C’est parce que le pilote est le décideur ultime, responsable de l’exploitation sûre de l’engin. De même, les chefs de projet jouent un rôle crucial dans les projets logiciels et peuvent être une source majeure d’erreurs conduisant à l’échec.
En 1986, la Bourse de Londres a décidé d’automatiser son système de règlement des transactions boursières. Sept ans plus tard, après avoir dépensé 600 millions de dollars, il a mis au rebut le développement du système Taurus, non seulement parce que la conception était excessivement complexe et lourde, mais aussi parce que la gestion du projet était, pour reprendre le mot de l’un de ses propres cadres supérieurs, « délirante. »Comme l’ont révélé les enquêtes, personne ne semblait vouloir connaître le véritable état d’avancement du projet, alors même que de plus en plus de problèmes apparaissaient, que les délais étaient manqués et que les coûts montaient en flèche.
La fonction la plus importante du chef de projet informatique est d’allouer des ressources à diverses activités. Au-delà, le gestionnaire de projet est responsable de la planification et de l’estimation du projet, du contrôle, de l’organisation, de la gestion des contrats, de la gestion de la qualité, de la gestion des risques, des communications et de la gestion des ressources humaines.
Les mauvaises décisions des chefs de projet sont probablement la principale cause des défaillances logicielles aujourd’hui. Une mauvaise gestion technique, en revanche, peut entraîner des erreurs techniques, mais celles-ci peuvent généralement être isolées et corrigées. Cependant, une mauvaise décision de gestion de projet — comme embaucher trop peu de programmeurs ou choisir le mauvais type de contrat – peut faire des ravages. Par exemple, les développeurs du système de réservation de voyages condamné affirment qu’ils ont été entravés en partie par l’utilisation d’un contrat à prix fixe. Un tel contrat suppose que le travail sera de routine; le système de réservation s’est avéré être tout sauf.
Les décisions de gestion de projet sont souvent délicates précisément parce qu’elles impliquent des compromis basés sur des connaissances floues ou incomplètes. Estimer combien un projet informatique coûtera et combien de temps cela prendra est autant de l’art que de la science. Plus le projet est vaste ou novateur, moins les estimations sont précises. C’est une blague courante dans l’industrie que les estimations des projets informatiques se situent au mieux à moins de 25% de leur valeur réelle 75% du temps.
Il existe d’autres façons qu’une mauvaise gestion de projet peut précipiter la disparition d’un projet logiciel. Une étude du Project Management Institute, à Newton Square, en Pennsylvanie., a montré que la gestion des risques est la moins pratiquée de toutes les disciplines de gestion de projet dans tous les secteurs de l’industrie, et nulle part elle n’est plus rarement appliquée que dans l’industrie informatique. Sans une gestion efficace des risques, les développeurs de logiciels ont peu de connaissances sur ce qui peut mal tourner, pourquoi cela peut mal tourner et ce qui peut être fait pour éliminer ou atténuer les risques. Il n’existe pas non plus de moyen de déterminer quels risques sont acceptables, ce qui rend les décisions de projet concernant les compromis presque impossibles.
Une mauvaise gestion de projet prend bien d’autres formes, y compris une mauvaise communication, qui crée une atmosphère inhospitalière qui augmente le roulement du personnel; ne pas investir dans la formation du personnel; et ne pas examiner l’avancement du projet à intervalles réguliers. N’importe lequel de ces éléments peut aider à faire dérailler un projet de logiciel.
Le dernier domaine sur lequel les enquêteurs se penchent après un accident d’avion est l’environnement organisationnel. La compagnie aérienne a-t-elle une forte culture de sécurité ou met-elle avant tout l’accent sur le respect de l’horaire des vols? Dans les projets informatiques, une organisation qui valorise l’ouverture, l’honnêteté, la communication et la collaboration est plus apte à détecter et à résoudre les erreurs suffisamment tôt pour que les reprises ne deviennent pas écrasantes.
S’il y a un thème qui traverse l’histoire torturée des mauvais logiciels, c’est un échec à confronter la réalité. À de nombreuses reprises, l’inspecteur général du département de la Justice des États-Unis, un groupe d’experts externes et d’autres ont dit au chef du FBI que le système VCF était impossible tel que défini, et pourtant le projet s’est poursuivi de toute façon. Les mêmes attitudes existaient chez les responsables du système de réservation de voyages, du système Taurus de la Bourse de Londres et du projet de contrôle du trafic aérien de la FAA – tous indicatifs de cultures organisationnelles motivées par la peur et l’arrogance.
Un rapport récent du National Audit Office au Royaume-Uni a révélé que de nombreux cas de projets informatiques gouvernementaux étaient recommandés pour ne pas aller de l’avant mais se poursuivaient de toute façon. Le Royaume-Uni a même un département gouvernemental chargé de prévenir les défaillances informatiques, mais comme le note le rapport, plus de la moitié des agences que le département supervise ignorent régulièrement ses conseils. J’appelle ce type de comportement une escalade de projet irrationnelle — l’incapacité d’arrêter un projet même s’il est évident que la probabilité de succès approche rapidement de zéro. Malheureusement, un tel comportement n’est en aucun cas unique.
En dernière analyse, les grosses défaillances logicielles ont tendance à ressembler au pire accident d’avion imaginable, où le pilote était inexpérimenté mais extrêmement téméraire, a volé dans une tempête de verglas à bord d’un avion non testé et a travaillé pour une compagnie aérienne qui a défendu la sécurité du bout des lèvres tout en réduisant la formation et la maintenance. Si vous lisez le rapport de l’enquêteur par la suite, vous seriez en train de secouer la tête et de demander: « Un tel accident n’était-il pas inévitable? »
De même, les raisons de l’échec des projets logiciels sont bien connues et ont été amplement documentées dans d’innombrables articles, rapports et livres. Et pourtant, les échecs, les quasi-échecs et les vieux mauvais logiciels continuent de nous affliger, tandis que les pratiques connues pour éviter les erreurs sont évitées. Il semblerait que l’obtention de logiciels de qualité à temps et dans les limites du budget ne soit pas une priorité urgente dans la plupart des organisations.
Cela ne semblait pas être chez Oxford Health Plans Inc., à Trumbull, Connecticut., en 1997. Le système de facturation automatisé de l’entreprise était essentiel à ses résultats, et pourtant, les cadres supérieurs étaient plus intéressés par l’expansion des activités d’Oxford que par la garantie que son système de facturation pouvait répondre à ses besoins actuels. Même si des problèmes se posaient, comme l’envoi des factures avec des mois de retard, les gestionnaires n’y prêtaient guère attention. Lorsque le système de facturation s’est effectivement effondré, la société a perdu des dizaines de millions de dollars et son action est passée de 68 à 26 dollars par action en une journée, effaçant 3,4 milliards de dollars de valeur d’entreprise. Les actionnaires ont intenté des poursuites et plusieurs agences gouvernementales ont enquêté sur la société, qui a finalement été condamnée à une amende de 3 millions de dollars pour violation de la réglementation.
Même les organisations qui sont brûlées par de mauvaises expériences logicielles semblent incapables ou peu disposées à apprendre de leurs erreurs. Dans un rapport de 2000, le Conseil scientifique de la Défense des États-Unis, un organe consultatif du Département de la Défense, a noté que diverses études commandées par le DOD avaient formulé 134 recommandations pour améliorer le développement de ses logiciels, mais que seules 21 de ces recommandations avaient été suivies d’effet. Les 113 autres étaient toujours valides, a noté le conseil, mais étaient ignorés, alors même que le DOD se plaignait du mauvais état du développement de logiciels de défense!
Certaines organisations se soucient de la qualité des logiciels, comme le prouve l’expérience de la société de développement de logiciels Praxis High Integrity Systems, à Bath, en Angleterre. Praxis exige que ses clients s’engagent dans le projet, non seulement financièrement, mais en tant que participants actifs à la création du système informatique. L’entreprise passe également énormément de temps à comprendre et à définir les exigences du client, et elle met les clients au défi d’expliquer ce qu’ils veulent et pourquoi. Avant qu’une seule ligne de code ne soit écrite, le client et Praxis s’entendent sur ce qui est souhaité, ce qui est réalisable et les risques encourus, compte tenu des ressources disponibles.
Après cela, Praxis applique une approche de développement rigoureuse qui limite le nombre d’erreurs. L’un des grands avantages de ce modèle est qu’il filtre les nombreux clients potentiels qui ne veulent pas accepter la responsabilité d’articuler leurs besoins informatiques et de dépenser le temps et l’argent pour les mettre en œuvre correctement.
Un certain niveau de défaillance logicielle sera toujours avec nous. En effet, nous avons besoin de véritables échecs — plutôt que de gaffes évitables — pour continuer à faire des progrès techniques et économiques. Mais trop de défaillances qui se produisent aujourd’hui sont évitables. Et à mesure que notre société s’appuie sur des systèmes informatiques de plus en plus grands, plus intégrés et plus coûteux, le coût de la défaillance peut devenir désastreusement élevé.
Même maintenant, il est possible de parier sur l’endroit où se produira la prochaine grande débâcle logicielle. L’un de mes principaux candidats est les systèmes informatiques qui résulteront de l’American Health Information Community du gouvernement américain, une collaboration public-privé qui vise à définir des normes de données pour les dossiers médicaux électroniques. L’idée est qu’une fois les normes définies, des systèmes informatiques seront construits pour permettre aux professionnels de la santé de tout le pays d’entrer les dossiers des patients sous forme numérique, donnant aux médecins, aux hôpitaux, aux assureurs et à d’autres spécialistes de la santé un accès instantané aux antécédents médicaux complets d’un patient. Les experts en soins de santé estiment qu’un tel système améliorera les soins aux patients, réduira les coûts d’environ 78 milliards de dollars par an et réduira les erreurs médicales, sauvant ainsi des dizaines de milliers de vies.
Mais cette approche n’est qu’un rêve si les pratiques logicielles et les taux de défaillance restent tels qu’ils sont aujourd’hui. Même selon les estimations les plus optimistes, la création d’un système de dossiers médicaux électroniques nécessitera des efforts de 10 ans, des coûts de développement de 320 milliards de dollars et des dépenses d’exploitation de 20 milliards de dollars par an — en supposant qu’il n’y ait pas de défaillances, de dépassements, de bulletins de calendrier, de problèmes de sécurité ou de logiciels de mauvaise qualité. Ce scénario n’est guère réaliste, d’autant plus que la plupart des experts en informatique considèrent la communauté médicale comme la moins informaticienne de toutes les entreprises professionnelles.
Les patients et les contribuables paieront en fin de compte le prix du développement, ou de l’échec, de ce genre de bogues. Compte tenu des pratiques informatiques actuelles, une défaillance est une possibilité distincte, et ce serait une perte d’une ampleur sans précédent. Mais alors, les pays du monde entier envisagent ou travaillent déjà sur de nombreuses initiatives de taille et d’impact similaires — dans l’aviation, la sécurité nationale et l’armée, entre autres domaines.
Comme l’électricité, l’eau, les transports et d’autres parties critiques de nos infrastructures, ELLES deviennent rapidement intrinsèques à notre existence quotidienne. Dans quelques décennies, une panne informatique à grande échelle deviendra plus qu’un simple inconvénient coûteux: cela mettra notre mode de vie en danger. En l’absence du type de changements à l’échelle de l’industrie qui atténueront les défaillances logicielles, dans quelle mesure sommes-nous prêts à jouer sur ces systèmes extrêmement coûteux et complexes?
Nous savons déjà bien faire des logiciels. Il est peut-être enfin temps d’agir sur ce que nous savons.