Prévoir deux personnes au lieu de cinq au début d’un projet, et c’est la catastrophe. TF1 Publicité a commis cette erreur, en 1997, sur un projet de refonte totale de ses applications métier. Selon une source proche du projet, à l’époque consultant, le choix le plus judicieux eût été de consacrer d’emblée une équipe plus importante sur l’intégralité du projet. Le manque de cadrage des ressources a obligé la filiale du groupe d’audiovisuel à s’y reprendre à deux fois. Pour la deuxième tentative, plusieurs dizaines d’informaticiens de chez Arthur Andersen sont intervenus en secours. Au passage, une précieuse année a été perdue.Anecdotique au premier abord, le ratage à TF1 Publicité est tout à fait commun. Le manque de réflexion lors de l’élaboration d’un cahier des charges ou, tout simplement, le manque de méthode peut mener à l’oubli d’un point crucial. L’Association française du génie logiciel (Adeli) estime d’ailleurs que “moins de 10 % des projets applicatifs respectent leur cahier des charges en livrant, dans les délais prévus et au coût prévisionnel estimé, un système offrant à ses utilisateurs le niveau de qualité requis “.Malheureusement, les techniques de conduite de projet – Merise en tête – sont truffées de pièges. “Un cahier des charges bâti selon le cycle Merise suit une chronologie précise, explique Jean-Pierre Vickoff, consultant spécialisé dans la conduite de projet. Elle comprend quatre niveaux successifs : conceptuel, organisationnel, logique et physique. ” Une séquence qui n’a plus lieu d’être aujourd’hui. Ainsi, le niveau d’organisation passe derrière le technologique, de plus en plus présent dans les projets ” modernes “. Ne pas en tenir compte ou, surtout, ne pas anticiper leur évolution probable, peut geler un chantier. Ou forcer à adapter des technologies obsolètes.Ce problème est fréquent dans le cadre des projets publics, dont le cahier des charges est souvent figé en raison de procédures d’appels d’offres complexes. Pour peu que le projet ait traîné, on se retrouve, au moment de l’allocation réelle des ressources ou de l’achat du matériel et du logiciel, en retard d’une technologie. Un responsable du projet de gestion de la connaissance à l’Armée de terre regrettait ainsi de n’avoir pu bénéficier d’une interface utilisateur de type navigateur internet, ni de sécurisation par carte à puce.
Conduite du changement, tests et ergonomie relégués à la fin
u-delà de cette approche ” ordonnée ” du cahier des charges, se pose le problème des questions annexes : la conduite du changement et tout ce qui a trait aux tests logiciels et à l’ergonomie, qui sont fréquemment traités en fin de parcours. Sur ce dernier point, certains sites de cartographie et de calcul d’itinéraires se sont laissés piéger. Donnant leurs indications de parcours en ville au mètre près – en non pas en fonction du nombre d’intersections ou de feux rouges -, ils s’avèrent peu pratiques à utiliser. Et le problème est quasi insoluble, puisqu’il faudrait reprendre en totalité une base de données conçue ” en dépit ” de l’utilisation du système.Cette précipitation et ce manque de contrôle risquent encore de se détériorer avec l’augmentation du nombre de microprojets. Par nature moins risqués, le Standish Group fait remarquer que leur accroissement ces derniers mois est inversement proportionnel au taux d’échec. C’est plutôt une bonne nouvelle. Malgré tout, ils risquent de développer le sentiment qu’un projet informatique, c’est facile, et que cela ne nécessite pas de cadrage poussé. Erreur : s’ils sont de plus en plus brefs, avec des délais et des budgets resserrés, les projets informatiques sont également de plus en plus transdomaines, multicompétences et multiresponsabilités.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
