Et le cahier des charges ?

Le cahier des charges est un élément clé dans tous projets informatiques impliquant différents sociétés ou différentes direction. J'avais eu débat à ce sujet avec Pierre en juin dernier. Aujourd'hui, Styven revient le sujet (et je suis d'accord avec lui) mais dans son domaine d’activité. L'occasion d’en rajouter une couche. 

En préambule, ne commençons pas à tortiller du cul. Nous ne chierions pas droit : le cahier des charges est important parce que c'est la base d'un accord contractuel entre un "client" et un informaticien. Ben oui, il faut bien payer…

Le cahier des charges est essentiel puisqu'il permettra au client de définir exactement ce dont il aura besoin. 

Beaucoup d'informaticiens développent leurs idées sans trop savoir où ils vont. 

Je vais citer un exemple. Quand on a crée les leftblogs en 2008, ce n'était qu'un groupe de discussions Google réunissant des blogueurs de gauche. Un jour, on a commencé à être un peu connus. Des copains connaissant un peu la technique ont dit « ah ben ça serait bien d'avoir un compte Twitter et une page (ou un groupe, à l'époque) Facebook. » Pas un d'entre eux ne s'est posé la question de ce qu'on allait en faire. Ils ont foncé, ont crée et puis plus rien. 

Ça n'est que trois ans après (un peu plus, même), quand j'ai décidé de remettre les leftblogs en ordre de marche pour les primaires du PS, que je me suis penché sur la possibilité d’utiliser ces machins pour diffuser les billets des blogs des membres du groupe. 

Ça parait idiot mais c'est ainsi : de nombreux projets informatique échouent parce qu'on a mal défini un besoin et les modalités de mise en œuvre, même quand c'est très simple. En l'occurrence, j'ai bossé sur ce projet avec Dada. Il nous a fallu tout ou au plus quelques heures pour mettre ça sur pieds dont la majeure partie à mettre dans l'agrégateur l'adresse de tous les flux après les avoir recensés. Il n’a fallu que quelques minutes pour les aspects techniques : la recréation des comptes et l’alimentation avec les flux RSS. Rien de plus simple !

L'inverse est également vrai. Un cahier des charges mal ficelé peut générer un projet extrêmement coûteux ou d'une rentabilité très faible. 

Reprenons mon exemple du groupe Leftblogs. 

On a commencé par formuler une "expression de besoin", à savoir utiliser des comptes Twitter et Facebook pour diffuser les billets des blogs des blogueurs du groupe. On aurait pu décider de faire un système où un groupe de personne ou chaque individu décide quels flux mettre, ce qui aurait nécessité le développement de quelque chose. Ce développement aurait été couteux et la rentabilité aurait été faible : il aurait fallu passer du temps à l’alimenter.

J’ai donc pris la décision : l’alimentation sera automatique et tous les billets de tous les blogs déclarés sera prise en compte.

Devant vos yeux ébahis, je vais résumer : nous étions partis avec des gugusses qui ont dit « ça serait bien d’avoir des comptes Twitter et Facebook pour les leftblogs, on va les créer tout de suite, c’est facile » à un cahier des charges fonctionnels : « il faut diffuser automatiquement les billets des blogs des membres du groupe Leftblogs dans les réseaux sociaux les plus en vue, à savoir Twitter et Facebook. »

A notre échelle, la différence parait évidemment dérisoire mais à l’échelle d’un vrai projet informatique, c’est énorme.

A ce stade, je vais reprendre un élément très important du billet de Styven : à ce stade, « une personne externe au projet doit pouvoir comprendre l'intégralité » du machin. Effectivement, à ce stade, n’importe quel type qui connaît un peu les blogs peut comprendre ce cahier des charges fonctionnel. J’aurais pu dire : « avec des outils, on va balancer les flux RSS des blogs du groupe dans Twitter et Facebook » mais une partie des gens ne savent pas ce que sont les flux RSS !

Comme le dit Styven, le Cahier des Charges a deux facettes, une fonctionnelle, telle que définie ci-dessus, une technique. Dans notre exemple, le volet technique n’est pas très important parce qu’il n’y a rien de plus simple. Je vais donc en présenter un autre : imaginiez que vous fassiez développer une application, que votre développeur le face sur Mac et que vous ayez un PC. Vous seriez dans la merde.

Il n’empêche qu’il y a deux volets techniques dans notre machin des leftblogs. La première est que les blogs doivent avoir des flux compatibles avec les machins du marché. La deuxième c’est que pour automatiser ce bordel, il faut que nous utilisions des produits du marché, compatible en amont avec ces flux RSS et en aval avec Twitter et Facebook. Ca parait évident à tout blogueur mais, pourtant, ça ne l’est pas nécessairement.

Un copain ma contacté récemment pour me demander comment diffuser automatiquement dans Twitter ce qu’il avait dans son site… mais c’était un site et pas un blog : pas de flux. D’où l’importance du cahier des charges techniques avant de commencer un projet.

A ces deux facettes, fonctionnelle et technique, j’en ajouterais bien une troisième, si Styven est d’accord : organisationnelle. Une fois que notre système est en place, il faut savoir comment gérer la liste des blogs et comment assurer la maintenance technique et les aléas. En français : comment on fait quand un nouveau blog apparaît dans la liste (ou qu’un blogueur décide de quitter le groupe) et comment on fait si Dadavidov et moi mourront subitement d’une affreuse cirrhose du foie ?

Evidemment, dans notre projet, il n’y a eu aucun cahier des charges formalisé !

Mais dans la vraie vie, j’ai vu de majestueux plantages…