Demandez à trois personnes au hasard de vous décrire sur une page les ” spécifications fonctionnelles ” pour dresser une table : vous aurez trois réponses différentes. Et tout le monde aura oublié quelque chose. Pourquoi s’obstine-t-on alors à élaborer des cahiers des charges sur des sujets mille fois plus complexes ?Trente ans après l’IBM 360, on en est toujours à la vieille recette de grand-mère, qui veut que l’utilisateur couche la quasi-exhaustivité de ses besoins dans un beau document, qu’il va ensuite signer – on n’a pas encore osé rajouter ” lu et approuvé “, mais c’est bien de cela qu’il s’agit. Une telle formalisation paraît a priori raisonnable, car elle engage le demandeur. Et pourtant, ce n’est pas parce qu’une chose paraît raisonnable qu’elle est nécessairement valable. Les résultats de cette approche sont bien connus : des cycles de développement qui n’en finissent pas (comptez de neuf à douze mois avant de sortir le moindre résultat, puis autant pour rectifier le tir), et des relations entre l’informatique et le business contractualisées à un point qui n’encourage pas l’initiative et la prise de risque.Cette manie des cahiers des charges épais et illisibles est-elle une spécificité bien française ? Hélas non ! Elle est internationale et sévit sur tous les continents. Même nos collègues anglo-saxons, soi-disant plus pragmatiques que nous, sont prisonniers du fameux ” Statement of Requirements “. Et, sans le sacro-saint ” sign-off “, ils ne commenceront rien.Peut-on vraiment transposer à l’informatique le modèle du bâtiment avec ses cahiers des charges, ses plans et ses chantiers ? L’expérience – amère – a démontré depuis bien longtemps que non. Mais, en attendant une révolution, la tradition convient parfaitement. Parce que, en cas de contestation, on peut se servir du fameux document comme de la carte ” Vous êtes libéré de prison ” dans le Monopoly.Alors, cahier des charges ou cahier décharge ? Une alternative existe : le JAD (Joint Application Design). Une approche qui accouche des vrais besoins en quelques jours, décrit processus et données dans une forme compréhensible (Merise, non merci !), qui ne pèse pas plus de vingt à trente pages. Si certaines entreprises ont mené des tentatives dans ce sens, cela n’a pas toujours porté ses fruits. En effet, il manquait souvent un maillon clé : la pratique du RAD (Rapid Application Development), qui permet aux utilisateurs de manipuler un prototype un à deux mois plus tard pour valider leurs besoins. Cette correction de trajectoire permet la livraison en trois à six mois (cycle complet) d’une première version sans surprise. Et donc en phase avec les attentes. Un bon exemple de maîtrise de ce duo JAD/RAD ? Les grands éditeurs de progiciels ERP et CRM, qui savent qu’entrer dans le cycle infernal des cahiers des charges peut se retourner contre eux. D’autant que ce n’est pas leur ” core business “. Ils ont donc tout intérêt à faire vite et bien – contrairement aux grands cabinets de consultants…Nos directions informatiques doivent changer radicalement de mentalité et privilégier des résultats rapides, sans couverture contractuelle. Une conformité intellectuelle et stérile par rapport à un document incompréhensible n’est d’aucune consolation si le résultat correspondant a un an de retard et quil ne répond pas aux vrais besoins.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
