Prototyper dès le cahier des charges ? Oui, 100 fois oui.

Par Élie Sloïm, le 18 janvier 2012, dans .

J’ai eu l’occasion récemment d’échanger sur Twitter avec Laurent Demontiers, ergonome et designer d’information (@l_demontiers) . Le sujet de nos échanges : faut-il créer un premier prototype, même basique, au moment de la rédaction d’un cahier des charges ?

A mon sens, le prototypage en amont permet au maitre d’ouvrage d’élever sa réflexion, de se poser les bonnes questions, de lever des ambiguïtés, et de prévenir des risques d’incompréhension de la part des différents intervenants. Pour ces raisons et d’autres que j’exposerai en détail dans ce billet, je réponds donc sans hésiter : oui, faites des prototypes le plus tôt possible.

A quoi sert un prototype ?

Il sert à vérifier la pertinence de l’architecture de l’information, à tester des principes de navigation mais aussi à valider la nature des contenus et des services et la façon de les mettre en œuvre dans une interface Web.

L’immense majorité des clients que nous rencontrons et qui souhaitent que nous rédigions leur cahier des charges ont quelquefois, mais pas toujours, leurs propres idées des contenus et services qu’ils veulent voir implémenter dans leur futur site. Ils ont au mieux quelques idées de ce qu’ils souhaitent obtenir comme architecture de l’information, comme navigation, et comme contenus et services. Souvent, ces idées et attentes sont très imprécises et notre rôle est justement de les affiner, de les organiser, de les formaliser et de leur faire valider.

Prévenir les risques

Le travail d’accouchement et de formalisation de ces éléments d’entrées dans le cahier des charges n’est pas facile. Il existe de nombreux risques :

  • Définir une architecture à plat (simple listing des rubriques et sous-rubriques), c’est bien. Mais rien ne remplace la mise en situation dans un prototype semi-fonctionnel : si l’architecture envisagée dans un cahier des charges n’est pas pertinente, un prototype permettra de s’en rendre compte bien plus facilement.
  • Un prototype permet de vérifier rapidement la pertinence de ce qu’on imagine, beaucoup plus concrètement qu’à partir d’un simple texte descriptif.
  • Décrire l’ensemble des éléments nécessaires à la navigation n’est pas simple. Le dessiner l’est beaucoup plus. Tous les éléments attendus, implicites mais non formulés parce que trop longs à écrire vont entraîner une multitude de risques de surcoûts qui sont évitables grâce au simple dessin d’un aperçu d’écran.
  • Les exigences fonctionnelles décrites dans les cahiers des charges sont souvent mal comprises des prestataires, très souvent pour des raisons de vocabulaire. Un prototype permet de lever un grand nombre d’ambiguïtés.
  • Un prototype permet de vérifier très facilement que de nombreuses bonnes pratiques qualité, ergonomie, et accessibilité seront respectées.

Pour quoi faire ?

Tous les risques que je viens de citer peuvent avoir une incidence majeure sur le cadre de la mission, sur les contraintes, et sur l’évaluation du travail à mener par les prestataires.

Dans un billet publié suite à notre échange sur Twitter, Laurent Demontiers écrivait : Un cahier des charges est un référentiel dont l’objectif premier est de préciser le cadre et les contraintes de la mission. Un cahier des charges permet aussi et surtout d’évaluer les propositions commerciales de prestataires sur des bases communes.

En réalité, prototyper dès le cahier des charges n’aide pas à évaluer les prestataires, mais le bénéfice est ailleurs : le prototype aide le maître d’ouvrage et le futur maître d’œuvre à se comprendre et permet de faire en sorte que les propositions commerciales soient plus précises, mieux chiffrées, plus pertinentes et donc plus faciles à évaluer et à comparer.

Quelques précautions

  • Il n’est pas forcément nécessaire de remettre le prototype avec le cahier des charges. Le premier rôle du prototype est d’aider le rédacteur du cahier des charges à valider la pertinence et la faisabilité de ce qu’il écrit.
  • Les prototypes utilisés en conception peuvent être joints au cahier des charges ou remis ultérieurement au prestataire qui aura été choisi.
  • En aucun cas les prototypes produits au stade du cahier des charges ne doivent être définitifs. Une phase de prototypage « fine » doit être effectuée ultérieurement, si possible par des professionnels. Elle servira à préciser les choix en fonction du budget validé.
  • Si les prototypes initiaux sont bons, il sera lors possible de les améliorer et de les creuser, s’ils sont mauvais il sera possible de s’y appuyer pour en étudier les défauts et prévoir des solutions alternatives.
  • En tant qu’assistant, si vous avez la possibilité de travailler en direct avec votre client, c’est encore mieux.

Vas-y Gribouille 😉

Créer un prototype au moment de la rédaction du cahier des charges est une mesure de prudence, de prévention des risques. Chaque minute investie sur du prototypage au moment du cahier des charges est une minute rentable.  Essayez, vous ne pourrez plus vous en passer.

Produire un cahier des charges sans dessiner au moins quelques aperçus d’écran me semble pour le moins dangereux. Une interface homme machine, finalement, ça se dessine, ça ne s’écrit pas.

Note : merci à Muriel de Dona et à Laurent Denis pour le coup de main sur ce billet.
Note 2 : au fait, moi c’est @eliesl, si vous voulez me suivre sur twitter 😉

15 commentaire(s)

  1. Par Frank Taillandier, le 18 janvier 2012 à 19 h 30 min :

    AMEN. Ceux qui répondent aux appels d’offres te remercient Saint Élie 😉

  2. Par Florent, le 18 janvier 2012 à 19 h 47 min :

    D’accord sur tout. Mais j’ajouterais deux ou trois mises en garde inspirées de ma faible expérience.

    Les deux écueils principaux que je vois dans la méthodo «on fait une conception et on écrit ça dans un cahier des charges figé pour faire un appel d’offre», ce sont:
    1. Les demandes peuvent être imprécises, avec un fort risque de mauvaise compréhension des offrants. (Cas de figure fréquent: le paragraphe discret que l’agence prestataire a zappé ou estimé sur une base «ouais ça ressemble à tel module existant ça va pas être long», et qui dans la tête du client correspond à une fonctionnalité critique et sur-mesure. À l’inverse, le prestataire qui se couvre au maximum et présente un devis largement au-dessus du budget.)
    2. Les solutions retenues dans le cahier des charges (solutions aux problématiques du client, voire à des questions techniques ou ergo) peuvent être mauvaises, ou sous-optimales.

    Un boulot de prototypage en parallèle de la conception du cahier des charges permet de grandement réduire le premier problème (imprécisions et malentendus). Cependant, il faudra éviter certains écueils:
    – Des prototypes qui couvrent une petite partie du projet seulement. Je ne sais pas à quel point il faudrait être exhaustif, mais si seules 10% des fonctionnalités sont prototypées je doute que les bienfaits attendus soient au rendez-vous.
    – Des prototypes qu’on joint au cahier des charges mais qui ne sont pas à jour (ils ont servi à la conception, on a mis à jour le texte du cahier des charges mais pas les prototypes). Ou l’inverse: prototypes à jour, texte du cahier des charges incohérent.
    – Des prototypes dont le statut dans l’appel d’offre n’est pas clair. (J’ai déjà croisé des «c’était un essai interne, sentez-vous libre de proposer autre chose» suivis quelques jours plus tard de «ah mais pas du tout! il faut respecter les prototypes fournis!»)

    J’ai très très peu d’expérience de l’AMOA mais là comme ça je conseillerais de faire des prototypes pendant la conception initiale, oui, mais de savoir précisément si ce seront des outils intermédiaires pour la rédaction du cahier des charges (dans ce cas, peut-être travailler uniquement au brouillon pour ne pas être tenté de se reposer dessus comme sur des documents finalisés…), ou bien si ce seront des éléments de l’appel d’offre (idéalement mis au propre et insérés dans le cahier des charges aux endroits pertinents plutôt qu’en annexe). Éviter les situations ambigües entre ces deux stratégies.

    Quant au deuxième problème que je pointais, à savoir une conception initiale qui s’attache à de mauvaises solutions, je doute que le prototypage y change quoi que ce soit. Sur ce sujet, on touche plutôt à la compétence des différentes personnes impliquées (MOA et AMOA), à la culture de l’entreprise, à du Waterfall vs. Agile, etc.

  3. Par pascal weber, le 18 janvier 2012 à 20 h 40 min :

    Pourquoi pas ? Mais avec des bémols.

    J’ai régulièrement des prototypes joints aux appels d’offres, malheureusement souvent réalisés en interne par une équipe chargée du projet qui n’a aucune notion d’ergonomie, d’architecture de l’info ou d’accessibilité et pour seule expertise une utilisation “familiale” du web… Le problème est qu’ensuite lorsqu’on tente de corriger les erreurs du prototype fourni, qui a souvent demandé un vain mais lourd travail, qui a ensuite été validé par quelques élus encore plus ignorants des problématiques du web, on se retrouve devant un mur. Enjoints d’exécuter la prestation selon le prototype fourni sans en changer un mot…

    Sur son blog Stéphane Deschamps relevait récemment la nécessité d’intégrer l’équipe technique en amont et de ne pas laisser la conception aux seuls clients et chef de projet qui, même en cumulant leurs expertises respectives, ne sont pas familiers de nombre de notions de base. Pour combler ces lacunes ils reprennent souvent des fonctionnalités aperçues sur des sites “concurrents” qu’un expert en accessibilité ou ergonomie aurait écarté d’emblée. Lorsqu’il s’agit d’une ville, par exemple, difficile ensuite de convaincre le client que ce qu’il a vu sur le site de telle ou telle grande ville est à proscrire… L’ultime argument devient alors : c’était dans le prototype du cc et vous l’avez accepté donc maintenant vous le faites sans discuter.

    Le prototype est évidemment incontournable lorsqu’il s’agit de valider des solutions. Mais à mon sens le premier souci est de réussir à poser les problèmes correctement. Quel est l’outil idéal ? Je ne l’ai pas encore trouvé. Demander au client de mettre sur la table les contenus qu’il est en mesure de fournir, de confronter ces contenus avec ses objectifs ainsi qu’avec les besoins des utilisateurs du site (personas etc) permet dans un premier temps d’ajuster la voilure et de commencer à approcher des problématiques “réelles” et à concentrer les efforts au bon endroit : les clients ont souvent tendance à être obnubilés par une poignée de fonctionnalités qui ne sont que des voeux pieux voire des lubies.

    Nombre de cc avec prototype fournis que j’ai pu avoir entre les mains passent à côté des vrais problèmes ou préconisent des solutions inadaptées, démesurées ou non conformes Il n’est pas rare par exemple de lire un chapitre sur la nécessité d’actualités défilantes et d’animations flash qui s’ouvrent en pop-up à l’ouverture d’une page, et de lire dans le paragraphe suivant la même nécessité absolue d’être conforme au rgaa… Pour quelle raison l’actu doit défiler et pourquoi un pop-up ? Ca n’est pas précisé.

    Bien qu’étant persuadé de la nécessité d’un prototype, je me méfie donc de celui fourni avec un cc. Pour ma part je considère que le prestataire doit être associé à cette démarche et que ça fait partie du travail qu’il doit effectuer avec le client. C’est même une partie importante de la prestation et celait me paraît même déplacé de demander au client de faire à ma place le travail pour lequel il me paie. L’état a-t-il fourni les plans à Pei lorsqu’il a lancé le concours pour la pyramide du Louvre ?

  4. Par karl, le 18 janvier 2012 à 21 h 10 min :

    Oui et Non. C’est le côté normand qui émerge.

    En fait cela dépend des projets. Le désir de vouloir tout contrôler dès le cahier des charges est parfois juste l’expression d’un mauvais découpage du projet. En fait après avoir vu nombre de projets débordés, je suis de plus en plus convaincu que d’entraîner un client dans un projet avec un prix fixe couvrant de l’idéation à la réalisation complète est un monstrueux mensonge que toute la profession s’entête à croire (du côté client comme du côté vendeur). 🙂

    Je suis pour découper le projet en phases individuelles et *indépendantes*. La première phase d’idéation et d’études pouvant même déboucher sur un « Vous n’avez pas besoin de (changer|créer) votre site »

    Cela ne se passe pas car tout le monde a peur. Le dir comm a peur d’avoir à justifier des dépenses sur de la réflexion et pas de produits touchables par le boss de la compagnie. L’agence a peur de ne pas avoir de contrats pour continuer à payer ses employés.

    L’enjeu des prototypes est aussi qu’ils ont tendance à mettre le client dans un état de « promesse faite » et si au cours du projet, l’idée initiale d’interface n’était pas bonne, le client va se concentrer sur le projet initial. Cela crée du conflit. Peu importe les avertissements préliminaires ou mentions noires sur blanc dans le contrat.

    L’architecte n’est pas le maçon.

  5. Par Stéphane Deschamps, le 18 janvier 2012 à 21 h 55 min :

    Bien. À moi, à moi, à moi ! 🙂

    Attention, quand tu racontes Élie on a l’impression que tu fais un prototype pour ton client. Or si le client te soumet un CDC et que toi tu lui fais un prototype pour voir si ça correspond à ton besoin, tu as donc travaillé en amont sans être sûr de te faire payer, et ça c’est du spec work et c’est mal. Les enfants, ne faites pas ça à la maison, Tonton Élie est un professionnel qui sait ce qu’il fait.

    Maintenant, si tu es AMOA et que tu réalises le prototype en étant payé pour le faire (et donc là tu participes au cahier des charges) alors je dis banco.

    D’autant que comme le souligne Karl, on peut aussi envisager, au mieux / au pire (choisissez selon que vous voulez gagner la fidélité du client pour quelque temps ou que vous vouliez emporter un marché), que le processus s’arrête là parce qu’on a vu les limites et que ça n’intéresse plus le client.

    Enfin, je rebondis sur ce que dit Pascal Weber : attention, un prototype fonctionnel, même fait par des gens pleins de bonne volonté, ça peut être une bouillie de balises et de JavaScript copiés-collés “parce que c’est un proto” et qui finissent par trouver leur chemin jusqu’à la prod.

    Ne riez pas, ne croyez même pas que je crie au loup : ça arrive.

    Tenez, même, des fois, des zonings dans PowerPoint faits par des ergonomes sont pris par le client pour argent comptant, et il les intègre tels quels en ne pigeant pas que l’ergo n’est pas un designer.

    Ne riez toujours pas, je l’ai vu faire.

    Bref, y’a intérêt à drôlement borner la chose, à mon avis.

    Mais ça se tente.

    Donc je vote “oui et non” comme Karl.

    (je ne suis pas sûr d’avoir fait avancer le débat, mais à tout le moins j’éclaire des écueils.)

  6. Par Stéphane Deschamps, le 18 janvier 2012 à 21 h 56 min :

    Oui tiens, le code HTML est affiché comme du texte et j’ai encore oublié. Un petit coup de nettoyage serait le bienvenu sur mon commentaire 😉

  7. Par Chob, le 18 janvier 2012 à 22 h 27 min :

    Autant je suis favorable au prototypage, autant je suis réticent à ce qu’il soit à la charge du donneur d’ordre. Son boulot est d’exprimer son besoin de manière la plus exhaustive possible dans le cahier des charges et de fournir aux prestataires tous les éléments nécessaires pour qu’ils puissent apporter une réponse pertinente mais aussi une interprétation. Un prototypage aussi en amont impose un cadre un peu strict, non ? Et dans la vraie vie, le prototypage est rarement dans les compétences du donneur d’ordre…

  8. Par Nico, le 18 janvier 2012 à 23 h 38 min :

    Je n’ai rien contre le prototypage, mais gare à ne pas le faire trop tôt : sauf projet très complexe (mais dans ce cas, le proto sera devisé comme tel), prototyper pour prototyper n’est pas une option : en tant que pro, il faut quand même être capable de réagir sans filet et sans être à côté de la plaque.

    J’ai vu des projets sclérosés par des excès de méthodologie là où l’expérience et la confiance auraient suffi largement. Limiter des risques, ok. Mais trop de limite de risques tue le plaisir. Je suis d’accord de rentrer dans l’arène avec une épée et un bouclier, mais pas en mousse non plus.

  9. Par Elie, le 18 janvier 2012 à 23 h 49 min :

    A lire vos déjà nombreux commentaires, il se dégage un message très fort : il faut faire très attention.

    Visiblement, et si j’en crois vos expériences et vos témoignages, prototyper très tôt et notoirement dès la phase de CDC est une arme à double tranchant.

    Cela n’est possible que moyennant un certain nombre de précautions et dans certaines limites. Parmi les précautions, la connaissance et la maîtrise de référentiels accessibilité, de guides ergonomiques, et bien sûr de bonnes pratiques qualité semble un pré-requis.

    De l’autre côté, vous soulignez également que souvent, le donneur d’ordre n’est pas le mieux placé pour faire ce genre de choses. Je suis d’accord. Ce billet a été écrit par un assistant à maîtrise d’ouvrage, et il doit y avoir un sacré bout de déformation professionnelle dans cette approche.

    En tous cas, je me régale à vous lire. Merci.

  10. Par Laurent Demontiers, le 19 janvier 2012 à 10 h 37 min :

    Bonjour, merci pour cet article et bravo pour ces arguments judicieux.

    Les commentaires précédents sont aussi tous très intéressants. Merci à vous tous.

    Je ne vais pas paraphraser l’article que j’ai écrit sur le sujet ni les commentaires postés par les autres.

    Pour synthétiser mon point de vue :
    il faudrait que tu précises la position dans laquelle tu te places : celle de l’AMOA qui intervient de manière rémunérée avant la maîtrise d’œuvre et qui participe à la rédaction du cahier des charges ? Ou celle du prestataire maître d’œuvre qui intervient après la rédaction du cahier charge par le client, mais qui prend le parti de produire un prototype à ses frais en avant vente pour bien comprendre les besoins du client ?

    Ensuite je vois qu’on a tous des méthodes différentes d’aborder les projets, et chaque projet mérite aussi une organisation particulière. Je suis totalement d’accord avec Karl qui préconise de segmenter l’assistance à la maîtrise d’ouvrage et la maîtrise d’oeuvre. C’est même une garantie de contrôle qualité et d’indépendance pour un annonceur de choisir des prestataires différents pour ces deux phases.

    Enfin comme le dit Chob , quelle que soit la phase durant laquelle les premiers prototypes sont réalisés, la priorité c’est de les faire réaliser par une ressource compétente. La plupart des wireframes ou des prototypes réalisés en interne par le client sont généralement bon à jeter.

    Donc réaliser des prototypes lors du cahier des charges oui, mais à condition qu’ils soient fait par un AMOA compétent pour le faire, et payer pour.

    Ensuite chaque maître d’oeuvre à ses propres méthodes, et si pour chiffrer tes devis en avant vente tu préfères passer par une phase de prototypage non rémunérée, j’imagine que tu limites le temps alloué à ce prototypage à quelques heures pour limiter le risque.

  11. Par Christophe C, le 19 janvier 2012 à 12 h 20 min :

    Que j’aime à lire ce genre d’échanges !

    Pour participer à ce débat et apporter notre expérience d’agence, nous “zonons” et “prototypons” également dès la réalisation du cahier des charges et des spécifications fonctionnelles. Si cela est budgétairement prévu ! Les zonings sont inclus dans le cahier des charges, éventuellement remplacés à terme par les maquettes graphiques.

    Pourquoi faire un propotype alors que nous ne le faisions pas auparavant ?
    Ma réponse est parce que la grande majorité de nos commanditaires ne maîtrisent pas nos différents corps de métiers digitaux. Ou pire : ils pensent connaître. Sur le mode “échanges” nous gagnons du temps en compréhension dès la conception ; et nous le gagnons aussi sur la suite de la production.

    Dès l’amont d’un projet, ces documents référents sont souvent amenés à évoluer car la conception nécessite de nombreux retours avec l’interlocuteur-décideur. Le prototype, validé par l’ensemble des équipes, permet en plus d’impliquer immédiatement cet interlocuteur qui s’accapare mieux “son” projet en le cernant visuellement mais pas graphiquement. Il perçoit mieux les enjeux et les questions associées à se (re)poser en terme d’architecture de contenu, de fonctionnalités interactives, de navigation et d’ergonomie, le tout adapté à sa cible (les personas comme les cibles marketing). Il a presque l’impression que son projet est déjà en train de se constituer…

    Ces interrogations ou remises en question donnent ensuite lieu à des réponses concrêtes et inscrites dans ce cahier des charges. Sorte de méthode Agile qui porte ses fruits d’après ce que nous constatons, mais qui surtout réduit les éventuels risques d’incompréhension ou de mauvaise conception. D’expérience, un client ne vous en veut jamais de rechercher la qualité !

    A l’inverse, le client-décideur qui ne veut pas de zoning ni de prototype (à moins qu’il ne l’ait déjà fait, et convenablement, de son côté) engage souvent le projet sur un mode difficile à terme, avec perte de temps et de confiance. Cela intervient fréquemment dès la maquette graphique qui fait office de remplaçant. Les A/R peuvent devenir conflictuels… alors, si on peut éviter 🙂

  12. Par Elie, le 19 janvier 2012 à 15 h 00 min :

    @stef : ayait, c’est nettoyé 🙂

  13. Par C3M, le 20 janvier 2012 à 10 h 38 min :

    cela se rapproche de la philosophie scrum, donc oui

  14. Par Da Scritch, le 23 janvier 2012 à 11 h 24 min :

    Je suis en plein dedans, en exé d’un cahier des charges qui manque cruellement de prototypage. On aurait par exemple vu que rafraîchir les données en XHR en changeant les critères de tri d’une table HTML, cela impactait tellement l’expérience utilisateur, que vu le nombre de lignes, il valait mieux laissait faire une lib JS avec l’ensemble des données chargées.

    Perso, je suis un sanguin, un actif, un violent : j’ai une idée, je code.
    Vaut mieux tester immédiatement si ça marche, que de se pâmer avec le client devant un bô dessin.

  15. Par Webbax, le 31 janvier 2012 à 16 h 05 min :

    Entièrement d’accord avec toi sur le principe du prototype, il faudrait pouvoir le faire à chaque fois pour garantir une certaine sécurité.

    Seulement, faire un bon prototype prend du temps, le budget client étant de plus en plus réduit, ne permet pas de se poser toutes les questions nécessaires. Si on gonfle le prix pour augmenter le temps de cette réflexion, très souvent le client va chercher ailleurs moins cher.

    Il faudrait donc détailler plus le cahier des charges, cependant, celui-ci peut-être presque infini, si on désire lister toutes les possibilités.

    En final, je pense que la meilleure méthode passe par une phase d’expérience répétée sur plusieurs clients, ce qui permet d’évaluer plus facilement les besoins et les points sensibles :

    – quels sont les clients à risque ?
    – est-ce que le client sait ce qu’il veut ?
    – quels sont les points qui font office de blocage dans le 90% des cas ?

    Mieux l’analyse est effectuée, moins il y a de surprises… mais si votre temps d’analyse est trop conséquent, les clients se tourneront vers d’autres prestataires, moins précis… mais meilleur marché.

Les commentaires sont fermés.