03 octobre 2012

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…

11 commentaires:

  1. Et si tu veux bien, j'en ajoute une quatrième : juridique ! Faisons simple : il faut protéger les données des gens, même s'ils le font mal eux-mêmes !

    RépondreSupprimer
    Réponses
    1. Oui et non. Pour ce qui nous concerne c'est un problème surtout fonctionnel. Ça deviendrait juridique si on veut que le développeur s'engage et qu'il doive décrire les modalités juridique de son engagement.

      Dans la pratique, les modalités juridique seront élaborées à l'occasion des contrats.

      Au stade du CdC, les aspects juridiques portent sur des aspects mineurs (pour reprendre l'exemple, qui sera propriétaire de @leftblogs, en l'occurrence moi, pour que Dadavidov ne soit pas emmerdé s'il diffuse des conneries. Donc, je mets dans le cahier : le compte Twitter sera déclaré avec une adresse mail au nom de jegoun, mais ce n'est qu'une bricole, qui pourrait aussi être réglé au moment du contrat).

      Supprimer
    2. Je suis plutôt d'accord avec Ladyappoline. Imaginons que je rédige un cahier des charges, que je consulte des prestataires et que j'en choisisse un, mais que celui-ci ne puisse répondre aux exigences juridiques de ma boîte ? J'aurais perdu pas mal de temps alors que si j'intègre les contraintes juridiques dès le départ, je m'évite les mauvaises surprises...

      Supprimer
    3. Je vais répondre comme la première fois : répondre aux exigences juridiques est un point fonctionnel tant qu'on n'arrive pas au contrat. Sinon, tu peux ajouter un tas d'aspects : ergonomie, performances,...

      Mais c'est un détail. Il y a bien deux volets de base : un technique et un fonctionnel. J'en ai ajouté un troisième, organisationnel, parce que la contrainte de coût est importante.

      Supprimer
  2. Tiens, je vais essayer de modéliser tout ça pour Adelia400 (si je retrouve le CD)

    Commençons par MERISE...

    RépondreSupprimer
    Réponses
    1. Ça existe encore ? On a dit que le CdC devait être compris par tout le monde. Donc il ne doit avoir aucun élément venant d'une méthode quelconque. C'est une erreur qu'on voit souvent. Dans une récente boîte, la méthode voulait que l'équivalent du CdC dans la terminologie maison comprenne des machins dont j'ai oublié le nom (ULM ?) totalement incompréhensibles pour le commun des mot mortels.

      Du coup, ils ont crée des cabinet d'étude pour faire l'intermédiaire ça a coûté la peau des fesses.

      Supprimer
  3. Un cahier des charges doit être compris par n'importe quel prestataire sinon il sert à rien !

    D'accord avec à peu près tout Nicolas, sauf les mots-clés associés à mon lien car je ne cherche pas à être référencé sur mon prénom :)

    Good job, tu vois, tu peux faire des articles sur le sujet !

    RépondreSupprimer
    Réponses
    1. Je ne fais pas des liens pour le référencement mais pour l'amitié, bordel. L'article était prêt dès 14 heures, mais je n'ai pas eu le temps de faire la mise en page. En outre, douterais-tu que je puisse faire un billet à n'importe quel sujet ? À demain !

      Supprimer
    2. C'est vrai cela ! je me fous du SEO, seuls comptent les copains !

      Supprimer
  4. C'est plus à la mode, les cahiers des charges, maintenant on parle de Brief. Il faut surtout soulever sa mèche longue quand on parle de brief et demander un story Board ou un wireframe.

    RépondreSupprimer

La modération des commentaires s'active automatiquement deux jours après la publication des billets (pour me permettre de tout suivre). N'hésitez pas à commenter pour autant !