Plus de 350 millions de francs engagés sur une période de deux ans sans la moindre application à la clé. En 1998, une société anglaise spécialisée dans les cartes magnétiques de fidélisation pour les grands pétroliers (Elf, Total, Shell, etc. ) se lance avec un prestataire dans la réécriture de toutes ses applications. Parmi celles-ci, de nom- breux composants obsolètes, qui ne passent pas l’an 2000. Si le cahier des charges s’avère solide, prestataire et client commettent une succession d’erreurs fatales, qui aboutissent à un véritable inventaire des pires mauvaises pratiques dans ce domaine.Parmi celles-ci : le directeur informatique ne s’associe pas au projet. Pire, il refuse les technologies préconisées par un cabinet de conseil et acceptées par sa direction générale, ainsi que le choix du développement par objets et la méthode de conduite de projet par développement rapide. Conséquence immédiate : maîtrise d’ouvrage et maîtrise d’?”uvre se retrouvent externalisées. Une formule particulièrement risquée, puisqu’elle ne laisse aucune place à l’entreprise pour, le cas échéant, rectifier le tir de ses prestataires.L’un des facteurs primordiaux de réussite d’un projet d’infogérance réside justement dans le contrôle absolu de ses sous-traitants. Une pratique qui doit être d’autant plus appliquée que la technologie utilisée est récente ou mal maîtrisée par les équipes internes. Impossible, dès lors, de corriger les dérives de prestataires peu expérimentés dans ce type de développement. Au final, les premières applications – livrées en retard à la société anglaise – sont bancales : le contour des objets reste flou et les briques logicielles ne correspondent pas aux fonctionnalités exigées par le cahier des charges. Mais ni la maîtrise d’ouvrage ni la maîtrise d’?”uvre n’ont intérêt à ce que le projet s’arrête ou se restreigne. La situation ne s’améliore donc pas. Et le projet est abandonné.
20 millions de dépensés sans produit à la clé
ontrôler le prestataire est également crucial lorsque les opérations précédant le lancement du projet ont été négligées. En particulier, l’analyse des risques techniques, organisationnels et financiers. Le Crédit commercial de France (CCF) en a fait les frais avec un projet de workflow visant à faciliter la gestion des contentieux. Initialement évalué à 4 millions de francs, ce chantier en avait déjà coûté 20 à la date de livraison sans qu’aucun produit ait vu le jour. Et le prestataire en demandait 30 de plus. Le chef de projet interne, dont les compétences se limitaient à la seule bureautique, n’a pas étudié les enjeux économiques et budgétaires. “Il s’avérait incapable de demander des comptes à une SSII qui non seulement programmait sans se soucier des coûts, mais cherchait en outre à se confectionner un progiciel, et non à réaliser une application spécifique“, se souvient un ancien cadre de la banque.Reste que les entreprises n’ont pas toujours les ressources nécessaires pour assurer le contrôle de leur prestataire et qu’elles augmentent ainsi les risques d’échec. “Lorsqu’ils deviennent chefs de projet, nos informaticiens ont une charge de travail supplémentaire. Ils ne peuvent pas toujours s’investir comme il le faudrait“, reconnaît Jacques Blondeau, DI d’Appia, société autoroutière. “Le coût de l’investissement des équipes en interne doit représenter environ 30 % du coût global d’un projet, estime pour sa part Jean-Luc Grobert, président de l’Adira (Association pour le développement de l’informatique en région Rhône-Alpes). Le reste est lié à l’intervention du prestataire et à l’achat de la technologie. ”
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
