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…
