Archives de catégorie : Entraide

Avoir une prise de notes efficace (deuxième partie)

Avoir une prise de notes efficace (partie 2)

Ce second article sur les prises de notes (niveau avancé) va vous proposer quelques techniques de notations textuelles et graphiques et vous présenter le contexte dans lequel elles s’appliquent. Il fait suite à Avoir une prise de notes efficace (partie 1).

Quel support utiliser pour la prise de notes ?

Compte tenu de la pluralité des supports physiques ou numériques, c’est un vaste sujet pour lequel il n’y pas vraiment de bonne réponse. Par conséquent, le plus important serait que celui qui note soit parfaitement à l’aise avec le support utilisé afin de ne pas ressentir de gêne technique. Ensuite, il faudrait faire en sorte que ce support soit également en adéquation avec le format de l’entretien : face à face ou en groupe, atelier de recueil de besoin ou brainstorming, etc.

Plutôt que de recenser les outils existant, il m’a paru plus intéressant de me concentrer sur ce qu’il me semble important de tracer lorsqu’on prend des notes.

Conseil générique

Déjà, quel que soit le format de l’entretien, il ne faut pas hésiter à utiliser un paperboard, surtout si ce que l’on a besoin de représenter peut prendre une forme graphique : diagramme d’activité (ou logigramme), de flux, d’état, de classe, etc.

La prise de notes en face à face

Dans un entretien en face à face, mieux vaudrait privilégier le support papier ou une tablette équipée d’un logiciel de prise de notes (Evernote par exemple) plutôt que l’ordinateur. Cela favorise l’échange (moins formel, plus convivial) et ne crée pas la barrière symbolique de l’écran.

La prise de notes face à un groupe

En groupe, l’usage de l’ordinateur s’avérera plus efficace et le problème de la barrière symbolique de l’écran ne se posera pas. Toutefois, et particulièrement si la réunion est « dissipée », que des conversations parallèles s’engagent, etc. cela ne sera pas suffisant pour canaliser les participants. Il faudra donc animer la réunion au paperboard de façon à recentrer l’attention de tous sur un élément visuel collectif.

L’usage des post-it est également très répandu et quand on est debout pour animer, que ce soit à déplacer les post-it ou à écrire sur un paperboard, il devient bien entendu très difficile de noter quoi que ce soit sur son ordinateur. Par conséquent, il s’agira de définir avec les participants au moins deux règles simples qui peuvent se combiner :

  • désigner dans l’assistance un rapporteur,
  • se mettre d’accord sur le fait que seules les choses validées par tous, sur lesquelles il y a consensus, seront notées sur le paperboard ou les post-it .

Toujours photographier sa prise de notes !

En sortie de réunion, n’oubliez pas de photographier les différentes pièces produites.

Elles pourront faire office à la fois de mémo, de compte-rendu de réunion et alimenteront bien entendu le livrable.

Que faudrait-il prendre en notes ?

A moins de manier la sténographie, tout noter exactement comme l’a dit notre interlocuteur est impossible. Il faut donc trier et ne conserver que l’utile, cette notion d’utilité pouvant varier en fonction du type de réunion. Nous allons en traiter deux, qui nous paraissent comme étant les principales lorsqu’on rédige un cahier des charges.

Mais en préambule, précisons tout de même un point qui nous semble primordial :

On ne devrait noter que ce qui est compris.

La prise de notes des consignes

Lorsque notre commanditaire nous transmet ses attentes, les éléments qui nous paraissent structurants sont finalement proches du concept de « ready » en agilité :

  • le chiffrage (en j.h et/ou en €) sur lequel on s’est accordé pour exécuter la tâche,
  • le périmètre et hors-périmètre de la tâche,
  • la date d’échéance.

Dans le cadre de la production d’un livrable (cahier des charges, spécifications fonctionnelles, Epic, Feature, user story, etc.), il conviendra de préciser :

  • le format attendu (World, Excel, PPT, ticket, email, etc.),
  • le contenu du livrable (enjeux, schémas et lesquels, décrits ou non, écrans, etc.),
  • ce que le livrable ne doit pas contenir,
  • le volume à produire (en pages, exigences/US, tickets, etc.).

La prise de notes en atelier de recueil du besoin

Les sujets pouvant être abordés en atelier de recueil du besoin sont bien sûr aussi nombreux que variés mais, dans le cadre du métier de Business Analyst / Product Owner, quatre éléments nous semblent prépondérants :

  1. les fonctionnalités (exigences, règles de gestion, structure de données),
  2. les concepts métier et leur définition, qui peuvent donner lieu à différents diagrammes (de classe, d’état, d’activité, de flux, de séquence, etc.),
  3. les motivations (soit au niveau des enjeux du projet, soit au niveau d’une fonctionnalité) et tout ce qui relève des enjeux en général : défauts et points forts, objectifs, périmètre et hors périmètre, risques, priorité, etc.
  4. les exemples partagés avec l’interlocuteur.

Cela constitue en quelque sorte le cœur de la prise de notes, les points qui demandent notre plus grande vigilance et qu’il est primordial de ne pas omettre ou déformer.

A cela, d’autres informations clés peuvent s’ajouter, telles que :

  • le nom d’une personne à rencontrer, son service, son rôle et ses coordonnées (email, téléphone),
  • des dates,
  • des actions à mener qui nous incombent ou qu’il nous faudra suivre et relancer,
  • etc.

Comment faudrait-il prendre ses notes ?

Nous pourrions distinguer deux types de prise de notes, textuelle et graphique et, au sein de la textuelle, séparer ce que l’on notera de façon « télégraphique » des « vraies » phrases.

La prise de notes graphique

Prise de notes niveau avancé
Exemple de prise de notes graphique

L’avantage de la prise de notes graphique, schématique, est qu’elle oblige à ne noter que l’essentiel, l’utile. C’est également une forme de note extrêmement synthétique qui laisse plus de temps pour interagir avec son interlocuteur.

Cependant, il ne faudrait pas confondre « dessin » et usage d’une forme normée de graphique, UML ou Merise par exemple. En effet, en l’absence de structure, et donc de codes de lecture, la prise de notes sera chaotique et ne permettra donc pas un questionnement structuré. Car, oui, la forme de la prise de notes conditionne fortement le fond et la cohérence des questions.

De plus, une forme graphique inventée sur l’instant aura une durée de vie extrêmement limitée. Rien ne garantit que vous serez toujours en mesure de comprendre ce que vous avez souhaité représenter une ou deux heures après l’entretien.

Par conséquent, je recommande d’utiliser les schémas uniquement si l’on est à l’aise avec leur formalisme et qu’ils ne sont pas un frein au questionnement et à la compréhension.

Bien entendu, pour des questions de rapidité, il vaudra mieux réaliser le schéma à la main plutôt que d’utiliser un outil de modélisation en temps réel.

Quels schémas utiliser pour prendre des notes ?

Sans énumérer tous les schémas existants, ce qui serait fastidieux, il en est qu’il me semble néanmoins important de maîtriser car répondant à des problématiques récurrentes dans les projets SI :

La table de vérité, extrêmement pratique pour traiter le sujet des habilitations à un système par exemple, ou encore dérouler un questionnement CRUD (Create, Read, Update, Delete, soit les fonctionnalités élémentaires d’un système informatique) sur les différents concepts métier identifiés. C’est une représentation rapide à faire, facile à valider et facile à modifier.

Les diagrammes :

  • de flux, afin d’identifier les acteurs d’un projet et les informations (flux) qu’ils s’échangent,
  • de classe, pour représenter efficacement les concepts métier d’une application (via les classes), les informations qui les caractérisent (via les attributs) et leur « mode » de communication (via le verbe d’association),
  • d’état, lorsqu’on s’intéresse au cycle de vie d’un système (par exemple, un DAB et ses états « en veille », « en passe », « disponible », « en rupture de billets », etc.) ou d’un concept métier (une commande « en cours de préparation », « expédiée », « livrée », « annulée », etc.),
  • d’activité, afin de représenter un processus métier par exemple.

Les bénéfices de la prise de notes graphique

Il sera toujours plus simple et plus rapide dans ces contextes de représenter graphiquement les choses. Cela vous aidera également à assurer la couverture exhaustive des cas et à les traiter avec un fil directeur (une suite logique dans le questionnement.)

La prise de notes textuelle

Tous les énoncés ne se prêtent pas à une représentation graphique, il faut bien parfois écrire. Mais quand faudrait-il faire des phrases et quand pourrait-on utiliser un style plus télégraphique, au risque de trop élaguer le propos et de ne pas être en mesure de le reconstituer au moment de la rédaction ?

En fait, l’une des clés, sans tenir compte de la mémoire, serait de savoir ce que l’on note et son caractère crucial / complexe. Prenons l’exemple suivant :

« Nous voulons moderniser le système de gestion des règlements client. Il faut pouvoir indiquer au niveau d’un client un délai de règlement. Nous avons besoin de pouvoir rapprocher les règlements constatés en banque avec les factures émises, comme ça nous pourrons identifier les factures non encore réglées. On doit tracer toutes les actions de relance avec les réponses apportées par les clients. On veut pouvoir catégoriser les clients selon qu’ils sont bons payeurs, payeurs moyens ou très mauvais payeurs. En effet, on veut pouvoir blacklister des clients : avec certains ne plus renouveler de commandes et avec d’autres interrompre les contrats en cours. »

Etape 1

Si nous notions :

  • Moderniser la gestion des règlements client
  • Ajouter le délai de règlement au niveau du client
  • Rapprocher les règlements des factures
  • Identifier les factures non réglées
  • Tracer les relances et réponses clients
  • Catégoriser et blacklister les clients (arrêter les commandes et contrats)

Nous ne perdrions pas d’informations clés.

Etape 2

On peut aller plus loin si l’on maîtrise le principe des abréviations. Cependant, attention : comme les schémas, les abréviations ont une norme. On peut certes avoir ses propres moyens mémo-techniques mais mieux vaudrait éviter d’inventer des abréviations sur le moment car le risque de ne plus savoir ce que l’on a voulu dire est élevé.

  • « Moderniser GE règlt cli (ou clt)
  • Ajouter délai règlt cli
  • Rapprocher règlt et fac (ou fact)
  • Id fac non réglées
  • Tracer relances et rep cli
  • Catégoriser et blacklister cli (arrêt cmd et ctr) »

En utilisant les abréviations connues[1], on constate que les verbes ne sont que très rarement abrégés. Concernant « contrat », j’ai utilisé ici « ctr » mais qui n’est pas reconnu en tant qu’abréviation « officielle ».

Par conséquent, si j’ai l’habitude d’utiliser cette abréviation précisément pour ce mot cela ne posera aucun problème. En revanche, si je l’ai inventé sur le moment, je pourrais par exemple la confondre avec « ctrl » et me dire que j’ai voulu exprimer la notion de « contrôle » : j’introduis alors une déformation du propos du fait de l’usage d’une abréviation avec laquelle je ne suis pas familiarisé.

Que noter sous forme textuelle ?

Nous pourrions dire que, dès lors que l’on utilise des schémas pour représenter tout ce qui peut l’être sous forme graphique, il ne resterait à noter que les :

  • fonctionnalités,
  • concepts métier et leur définition,
  • motivations,
  • exemples.

Il semblerait que le style télégraphique soit particulièrement bien adapté pour transcrire des motivations et des fonctionnalités.

En revanche, les définitions, les exemples et certaines règles de gestion semblent imposer une écriture plus complète, sous peine de trop dénaturer ce que l’on aura mis tant d’effort à reformuler et à faire valider en temps réel. Par conséquent, il est parfois nécessaire de temporiser l’entretien et de prendre le temps de noter intégralement une phrase.

Par exemple, si notre interlocuteur nous dit que seuls les concurrents de plus de 16 ans peuvent s’inscrire à la course, nous ne devrions pas uniquement noter : « ctrl âge cct. » Nous pourrions retranscrire précisément la règle, en l’écrivant pendant notre reformulation : « donc, ce que vous me dites, c’est que seuls les concurrents ayant au moins 16 ans à la date de départ de la course doivent pouvoir s’inscrire. »

Cependant, si je maîtrise parfaitement les codes de cette écriture, il m’est également possible d’utiliser un langage formel pour représenter textuellement une règle. Ainsi, « seuls les concurrents ayant au moins 16 ans à la date de départ de la course doivent pouvoir s’inscrire » = « concurrent.âge >=16 ».

Ce type de notification induit cependant une difficulté : il faut savoir identifier en temps réel les classes et les attributs et la notation peut vite devenir complexe à manipuler si la règle que nous souhaitons noter imbrique plusieurs classes et plusieurs attributs.

En espérant que cet article vous aidera dans vos futures prises de notes. Si vous êtes intéressés pour en apprendre davantage sur le langage formel, n’hésitez pas à laisser un message sur l’article !

Vous êtes libre de vous inscrire à notre newsletter en dessous de l’article garantie 100% sans spam. Vous recevrez à cette occasion notre bonus, un mini guide pour bien commencer votre cahier des charges.

Au plaisir !

[1] https://meltingmots.com/

7 règles pour démarrer son cahier des charges

7 règles simples pour bien démarrer son cahier des charges… et donner de la visibilité !

7 règles simples pour bien démarrer son cahier des charges

Votre commanditaire vient de vous confier la tâche de rédiger un cahier des charges, par exemple dans le but de lancer un appel d’offres dans le secteur public ou pour une entreprise privée. Problème : cet exercice ne vous est pas du tout familier et votre entourage, professionnel comme personnel, n’est pas en mesure de vous aider.

Ne souriez-pas, cette situation est assez commune dans bon nombre d’organisations. J’ai déjà pu observer que ce travail, qui nécessite tout de même une certaine expérience et un minimum de technicité, était même parfois confié à des stagiaires ou des alternants… Mais que l’on soit junior ou plus aguerri, j’observe régulièrement deux écueils majeurs dans l’acte de rédaction :

  • on se jette à l’assaut du document sans trop vraiment savoir ce qu’il doit contenir,
  • il est difficile de dire objectivement quand on aura terminé.

C’est en partant de ce constat que je me suis dit qu’un article sur 7 règles simples à appliquer pour bien démarrer son cahier des charges pourrait être utile à beaucoup d’entre vous. J’en prépare un autre sur les indicateurs de pilotage clés, n’hésitez pas à me dire en commentaire si cela vous intéresse !

Suis-je prête, suis-je prêt ?

Suis-je prête, suis-je prêt ?

Avant même de se lancer dans la rédaction de son cahier des charges, il faudrait déjà savoir précisément ce que l’on doit écrire. Cela est tellement évident que le fait de le rappeler semble totalement superflu. Et pourtant… Que celui ou celle qui n’a jamais passé des heures de travail à rédiger des éléments qui ont ensuite été supprimés du document me jette la première pierre ! (aïe !)

Oui, il est primordial de définir le plus en amont possible les attendus de notre commanditaire afin de maximiser nos chances de donner pleine et totale satisfaction. En effet, un démarrage mal cadré présage rarement de quelque chose de bon en sortie…

C’est pourquoi je vais tenter de vous faire profiter de 7 règles simples qui vous permettront de démarrer plus sereinement votre cahier des charges.

7 règles simples pour bien démarrer son cahier des charges

1 : S’accorder sur le chiffrage

Partez toujours de ce postulat : un commanditaire, quel qu’il soit, ne fait jamais de chèque en blanc. Par conséquent, ne pas connaître le budget (en euro ou la charge en jour.homme) qu’il est prêt à vous allouer pour mener à bien le cahier des charges est un risque qu’il vaut mieux éviter de prendre.

Les raisons paraissent évidentes :

  • Si, pour vous, le travail à réaliser est d’une telle ampleur que vous prenez 10j.h pour le faire alors que votre commanditaire considère qu’une première pré étude de 3j.h aurait été suffisante, vous ne donnerez pas satisfaction.
  • Si votre commanditaire attend un travail fouillé de 10j.h et que vous survolez le sujet en seulement 3j.h, vous ne donnerez pas non plus satisfaction.

CQFD : vous raterez à tous les coups.

Par conséquent, mettez-vous d’abord d’accord sur une valeur. Elle pourra toujours être réajustée au fil de l’eau… mais seulement si vous avez des éléments factuels (des chiffres) à avancer, surtout s’il s’agit de demander une rallonge !

2 : Connaître le format attendu

Là encore, j’enfonce peut-être une porte ouverte mais, lorsque vous rédigez un document, êtes-vous toujours certain du format sous lequel il est attendu ? Devez-vous rédiger sous Word ? Faire un PowerPoint ? Un tableau Excel ? Un email ? Utiliser l’outil de ticketing de votre organisation, Jira ou Mantis par exemple ? Confluence ? Axure ? Etc.

Ne faites pas fausse route en décidant vous-même du format qui vous semble le plus adapté ou avec lequel vous êtes le plus à l’aise. In fine, c’est bien votre commanditaire qui exploitera le document, c’est donc lui qui devra se sentir le plus à l’aise avec.

3 : Connaître le contenu attendu…

Aborder le sujet du contenu signifie que le besoin a déjà un peu maturé et que le commanditaire sait plus ou moins ce qu’il souhaite. Au minimum, je vous recommande de poser les trois questions suivantes :

  1. Faut-il définir les enjeux du projet ?
  2. Le document doit-il contenir des schémas (processus, flux, etc.) ou même des maquettes d’écrans ?
  3. Quel est précisément le périmètre fonctionnel à couvrir ?

Cela est certes très macro mais, au moins, vous saurez sur quoi vous devez vous focaliser. Ensuite, le niveau de détail et de qualité variera en fonction de la charge allouée et du délai (j’y arrive un peu plu bas).

4 : … et le contenu non attendu (ils n’en veulent pas !)

oui ou non

Hé oui ! S’il est très important de savoir ce que doit contenir le cahier des charges, il l’est tout autant de savoir ce qu’il ne doit pas contenir. Dit autrement : Qu’est-ce qui pourrait figurer dans l’étude mais que votre commanditaire choisit volontairement d’exclure ?

En effet, il s’agit d’optimiser votre production dans le temps qui vous est imparti. Gaspiller bêtement de l’énergie à rédiger des choses qui seront supprimées du document, c’est frustrant et c’est une source de stress inutile.

De plus, si tous les intervenants partagent cette information, cela vous protège d’éventuels actes de mauvaise foi. Si un élément a été exclu du périmètre de l’étude, personne ne pourra vous reprocher de ne pas l’avoir traité ;-). Et si pour une raison quelconque il fallait le réintégrer au cahier des charges, alors vous serez tranquille pour renégocier le budget ou le délai… 😉

5 : Dimensionner le volume à produire

Ce point peut demander un peu d’expérience mais il est important d’avoir une estimation, une fourchette, du volume à produire, que ce soit en nombre de pages, en nombre de fonctionnalités et, pour les plus aguerris : user stories, exigences, tickets, etc.

Pourquoi est-ce important ?

D’une part, si l’on n’a pas cette estimation initiale, il sera ensuite quasiment impossible de dire si oui ou non on touche au but, si l’on prévoit de lourds dépassements ou si au contraire on a surévalué la tâche.

D’autre part, une fois mis au regard de la charge, cela permet d’avoir une idée de la productivité attendue… et d’alerter en conséquence le cas échéant !

En effet si, par exemple, je n’ai que 2j.h pour produire un cahier des charges de 20 pages, ce n’est pas la même chose que d’en avoir 10, ou 20, etc. Donc, est-ce que la charge que l’on m’octroie est cohérente avec le volume que j’ai à produire ? Et ce peu importe le délai ! Que j’ai un délai de 4 jours pour utiliser mes 2j.h ou un délai de 3 semaines, il reste que je dois toujours produire 20 pages en 2j.h (bien entendu, je postule ici que je suis seul sur le projet).

A l’inverse, si je n’ai ni charge ni idée du volume à produire alors comment puis-je alerter mon commanditaire sur d’éventuelles dérives ?

6 : Borner dans le temps

Un projet a certes une date de début mais il a surtout une date de fin. Afin de s’organiser au mieux en fonction des tâches, de leur charge et de leur priorité, j’ai besoin de savoir à quelle échéance je dois rendre mon travail. Là encore, cette information est précieuse pour pouvoir anticiper des dérives et remonter des alertes, et valider à temps (avant la date buttoir… ;-)) !

agenda

Par exemple :

  • J’ai 5 jours de délai.
  • Avec une charge de 2j.h.
  • Je dois produire 10 pages.
  • J’ai consommé 1j.h sur 3 jours de délai.
  • J’ai produit 4 pages.

Vais-je rendre mon travail dans les temps ? Cela dépend de beaucoup de facteurs, notamment la qualité (Q) attendue, les coûts (C) et le délai (D). Un article sortira très prochainement pour détailler les différentes options possibles.

Ne vous mettez pas en surcharge

Si vous allez déborder, pas de panique ! La première chose à faire n’est pas d’essayer de faire rentrer plus de jours que ne peuvent en contenir les 2j.h alloués en faisant des heures supplémentaires et en travaillant le week-end sans le dire ! Commencez plutôt par alerter votre commanditaire en lui rapportant ces faits. Peut-être qu’il augmentera votre charge, peut-être qu’il diminuera le périmètre à couvrir, peut-être qu’il abaissera la qualité attendu, peut-être qu’il abandonnera le projet car son ROI (retour sur investissement) n’est plus intéressant, etc. Bref, il existe des tas de scénarios possibles !

Et dans tous les cas, on vous sera reconnaissant d’avoir pris les devants.

Pour en savoir plus sur le triangle QCD, vous pouvez vous reporter à l’article ci-joint : https://organisologie.com/comment-sorganiser/comment-atteindre-ses-objectifs/plan-action/retroplanning/triangle-qcd/

Ne consommez pas d’avantage sans en informer le donneur d’ordre

Une autre option à éviter est la suivante : ne pas informer votre commanditaire de la surcharge, consommer plus que ce qu’il vous a donné et le mettre ensuite au pied du mur ! Un commanditaire préfèrera (presque) toujours qu’on lui remonte une alerte anticipée de dérive (de charge, de délai, de pages, etc.) plutôt que de devoir payer plus sans avoir eu le choix d’arbitrer.

En effet, si pour lui il est acceptable de payer 2j.h de travail pour le document demandé, il considère peut-être que plus rend ce même document trop coûteux pour l’importance qu’il y accorde !

7 : Définir les priorités

Au sein de votre organisation, vous avez certainement plusieurs sujets sur le feu et les tâches s’accumulent. Comment les gérerez-vous ?

  • Traitez-vous les demandes dans leur ordre croissant d’arrivée en faisant en sorte que les tâches les plus anciennes soient celles que vous acheviez en premier ?

ou bien

  • Le dernier qui a parlé est-il servi en premier, et ce même si la tâche est moins importante que les autres ? Ou plus longue ? Voire les deux ?

Concernant la gestion des priorités, je préconise deux choses.

Le plus rapide en premier

Vous pouvez adopter une approche « Quick win » (gagner rapidement) qui consiste à toujours commencer par les tâches les plus rapides à faire de façon à ce que votre commanditaire voit que les choses avancent.

vitesse manège

Dit autrement, si vous avez trois tâches à exécuter, une de 1 heure, l’autre de 3 heures et la dernière de 2 jours, commencez par celle d’une heure.

En montrant à votre commanditaire que vous faites bouger les choses et que vous clôturez des sujets, vous le mettrez plus facilement en confiance, ce qui vous permettra de travailler sereinement sur la tâche la plus longue (ce qui ne vous dédouane pas de donner de la visibilité sur l’avancement).

A l’inverse, commencer par la tâche la plus longue, et pour peu que génériez un effet tunnel (votre commanditaire n’a aucune visibilité sur l’avancement de la tâche), est le meilleur moyen pour qu’il s’inquiète ! Ne vous étonnez pas s’il vous demande toutes les deux heures où vous en êtes, ce n’est pas qu’il est pressant, c’est juste qu’il n’est pas en situation de confiance !

Une priorisation concertée

Même si vous pouvez avoir votre idée des sujets les plus prioritaires et avoir fait un premier classement selon leur durée, je recommande de discuter de la priorité avec le commanditaire.

N’oubliez pas, aussi trivial que ce soit : c’est lui qui vous rémunère ! Donc ses priorités deviennent les vôtres et l’ordre d’exécution des tâches peut donc différer.

Il s’agit donc de ne pas écouter sa tendance naturelle (soit commencer par ce qui nous plaît le plus, soit « manger sa grenouille » au plus tôt) mais bien de s’assurer que l’ordre d’exécution des tâches réponde aux besoins prioritaires du commanditaire ! Parfois, cela ira dans votre sens naturel, parfois non. Il faut faire avec 🙂

Synthèse des 7 règles simples pour bien démarrer son cahier des charges

  1. S’accorder sur le chiffrage
  2. Avoir le format de livrable attendu
  3. Connaître le contenu attendu
  4. Connaître le contenu non attendu
  5. S’accorder sur le volume à produire
  6. Avoir une date d’échéance
  7. Prioriser les tâches

Et vous, pour démarrer un cahier des charges, qu’elle est votre tâche préférée ?

N’hésitez pas à nous répondre en commentaire ou à vous abonner à notre newsletter en bas de cette article. Venez partager votre expérience en commentaire sur les sujets en lien avec les cahier des charges !

Une « classe association », qu’est-ce que c’est ?

Tentative de définition d’une classe association

Exemple de classe association

Une « classe association », qu’est-ce que c’est ?

Si vous avez été amené à modéliser des concepts métier (un diagramme de classe au sens UML) ou plus simplement à devoir lire un diagramme de classe, alors la représentation ci-dessus ne vous est peut-être pas inconnue.

Mais que signifie-t-elle réellement ? Comment la lire et quand l’utiliser à bon escient ? Tel est l’objet de cet article qui, je l’espère, vous aidera à mieux comprendre la technique de la classe association.

En modélisation UML des données, une « classe association » est une classe à la jonction de deux autres classes. Elle porte des informations, que l’on appelle « attributs », qui sont en dépendance directe des deux autres classes et qui ne pourraient se mettre ni dans l’une, ni dans l’autre.

Bon, vous me direz qu’avec cela, on n’est pas beaucoup plus avancé. Je vais donc illustrer par des exemples. Je préciserais quand même que cet article s’adresse plutôt à des gens qui savent déjà un peu modéliser. A la fin, je vous donnerai une astuce pour vous passer de l’utilisation d’une classe association. Cela permettra aux plus néophytes de se sortir des situations complexes.

Quand peut-il y avoir une classe association ?

Exemple de classe association

Il ne peut y avoir une classe association que si l’association entre les deux autres classes a de part et d’autre une multiplicité maximum égale à « plusieurs », représentée par le symbole « * ».

Dans l’exemple ci-dessus, il y a bien « * » du côté du concept A et du concept B, il est donc possible de mettre une classe association. Dans tous les autres cas, cela constituerait une erreur de modélisation. Pour information, la valeur de la multiplicité minimum (0 ou 1) n’entre pas en ligne de compte.

En synthèse, voici la liste des cas envisageables :

  • Concept A 0 ou 1..1 —————- 0 ou 1..* Concept B : pas de classe association possible
  • Concept A 0 ou 1..* —————– 0 ou 1..1 Concept B : pas de classe association possible
  • Concept A 0 ou 1..* —————– 0 ou 1..* Concept B : classe association possible

Y a-t-il toujours une classe association ?

Exemple de cas sans classe association

On pourrait penser que dès lors qu’il y a une association entre deux classes avec « * » en multiplicité maximum, alors il y a forcément une classe association. Cela est vrai si l’on se place du point de vue d’un développeur fabriquant sa base de données. Mais lorsqu’on travaille à un niveau conceptuel métier, ce qui est le cas lorsqu’on rédige un cahier des charges, alors cela n’est plus du tout systématique.

Pour illustrer cela, je vais prendre un exemple simple. Imaginons que vous deviez rédiger un cahier des charges pour gérer les traducteurs d’une maison d’édition. Un traducteur peut traduire une à plusieurs (*) langues et une même langue peut être traduite par un à plusieurs (*) traducteurs. Le système à implémenter devra donc permettre de renseigner cela et de dire précisément quel traducteur traduit quelle(s) langue(s).

Exemple d'association many to many

Dit plus clairement, le traducteur François traduit l’anglais et l’espagnol et la traductrice Claire traduit l’anglais et l’allemand. Un traducteur se caractérise par son nom et sa date d’entrée dans la maison d’éditions (ce sont ses attributs) et une langue se caractérise par son nom. Souvenez-vous ce que j’ai écrit plus haut : « une classe association vient porter des informations, que l’on appellera « attributs », qui sont en dépendance directe des deux autres classes« . Dans le cas exposé ici, aucun attribut n’est en dépendance à la fois du traducteur et de la langue : nul besoin de représenter une classe association dans la vision « métier » des choses.

Exemple de cas avec une classe association

Toujours dans le cadre de notre maison d’édition, vous devez à présent gérer le fait qu’un traducteur n’a pas le même niveau de maîtrise pour chacune des langues qu’il pratique. François a l’anglais pour langue maternelle et a un niveau courant en espagnol. Quant à Claire, elle est bilingue sur l’anglais et l’allemand.

Où mettre cette nouvelle information qu’est le « niveau » et qui est très importante pour le métier ? Comment représenter graphiquement le fait que pour chaque occurrence de couple « traducteur – langue », je dois pouvoir indiquer le niveau de maîtrise ?

Option 1

Exemple d'association many to many

Option 1 : je dis que le niveau est un nouvel attribut du traducteur. Problème : le niveau que j’attribuerai au traducteur sera le même pour toutes les langues qu’il traite. Pourquoi ? Parce que l’attribut « niveau » du concept « Traducteur » ne peut prendre qu’une seule valeur à un instant T, donc si je dis que François a un niveau « langue maternelle », cette valeur vaudra pour toutes les langues auxquelles il est rattaché : l’anglais et l’espagnol. Or, au regard de l’énoncé, on sait que cela est faux.

Option 2

Exemple d'association many to many

Option 2 : je mets le niveau sur la langue. Quelques secondes de réflexion suffisent à comprendre que cela n’est pas non plus un choix pertinent.

Option 3

Exemple de classe association

Option 3 : je fais appel à la classe association, que je pourrais appeler « Niveau » et sur laquelle je mettrai l’attribut « libellé », la valeur de ce niveau dépendant à la fois du traducteur et de la langue.

Une fois traduit en termes métier, cette représentation graphique signifie bien que pour chaque couple « Traducteur – Langue », je pourrai renseigner le niveau adéquat.

Ainsi :

  • François – Anglais – Langue maternelle
  • François – Espagnol – Courant
  • Claire – Anglais – Bilingue
  • Claire – Allemand – Bilingue

Le piège derrière la classe association

On pourrait avoir le réflexe de systématiquement utiliser la classe association dès lors que les principes précédents sont respectés : association entre deux classes avec « * » de chaque côté et présence d’au moins un attribut en dépendance directe des deux classes. Ce serait cependant une erreur de ne pas prendre un temps de réflexion pour bien approfondir le sujet.

En effet, la classe association a un signification bien précise et est porteuse d’une contrainte forte que je vais illustrer via un deuxième exemple.

Cas concret

Problématique à résoudre

Vous devez rédiger un cahier des charges pour une plateforme permettant à des écoliers de faire des exercices en ligne. Un écolier peut passer plusieurs exercices et un même exercice peut bien sûr être passé par plusieurs écoliers, ceux d’une même classe par exemple.

Pour chaque passage d’un exercice, le métier a besoin de pouvoir consulter la date de passage ainsi que le score obtenu par l’écolier.

Exemple de classe association

La classe association comme solution « réflexe »

Premier réflexe, naturel : je crée une classe association « Passage » où je vais stocker les deux attributs « date » et « score ».

Cela pourrait donc donner :

  • Nadia – Exercice 1 – 20/05/2021 10h05 – 78%
  • Nadia – Exercice 2 – 20/05/2021 11h01 – 95%
  • Adrien – Exercice 1 – 21/05/2021 08h33 – 80%
  • Adrien – Exercice 2 – 20/05/2021 08h45 – 63%
  • Etc.

A priori, tout va bien. J’enregistre les informations souhaitées et mon système fonctionne. J’ai cependant oublier de poser une question primordiale à mon interlocuteur métier : un écolier peut-il passer plusieurs fois le même exercice ? Par exemple pour le refaire s’il a obtenu un score insuffisant au premier passage.

Ne tombez pas dans le piège de la classe association systématique

Car c’est là le piège de la classe association : cette représentation implique qu’il ne peut pas y avoir deux occurrences d’un même couple de classes ou, pour illustrer avec l’exemple, cela signifie que Nadia ne pourra pas passer plus d’une fois chacun des exercices mis à sa disposition. Un seul passage autorisé pour l’exercice 1, l’exercice 2, etc.

Exemple de jeu de données

Pour bien comprendre cela, il faut se plonger un instant dans la base de données. Que va-t-il se passer lorsque Nadia va réaliser l’exercice 1 ? Le système va automatiquement créer une occurrence de classe association dont l’identifiant sera composé de celui de Nadia (écolière n° 345) et de celui de l’exercice (n° 61). Et comme il ne peut pas exister en base de données deux occurrences de classe ayant le même identifiant, cela signifie bien que le couple « Nadia – Exercice 1 » ne pourra pas être enregistré deux fois.

L’impact métier dans ce cas précis est donc que l’écolier ne peut pas refaire plusieurs fois un même exercice en vue de s’améliorer.

Conséquence du piège

L’une des première choses à faire lorsque vous pensez représenter une classe association, c’est de bien s’assurer auprès du métier qu’il ne peut pas y avoir de répétition (plusieurs occurrences) d’un même couple de classes.

Dans l’exemple de la maison d’édition et des traducteurs, une fois que l’on a indiqué que l’anglais est la langue maternelle de François, cela n’aurait pas de sens de faire ensuite une deuxième occurrence pour dire qu’il est bilingue sur cette même langue. Donc, dans ce cas, la classe association est parfaitement utilisée.

En revanche, dans le cas des écoliers et des exercices, si le métier vous dit qu’il s’agit d’exercices :

  • à passage unique, alors la classe association se justifie pleinement,
  • pouvant être passés plusieurs fois afin de s’entraîner et de progresser, alors la classe association n’est pas la bonne représentation graphique.

Si l’on ne clarifie pas cela au plus tôt avec le métier, l’impact sur le système développé peut être énorme, et surtout très coûteux. En effet, imaginons que vous donniez votre modèle avec la classe association au développeur. Lui comprend normalement très bien la problématique exposée ci-dessus et les fonctionnalités qu’il développera répondront au besoin exprimé par votre schéma.

Je vous laisse réfléchir à la déconvenue du  métier lorsqu’il effectuera la recette et qu’il essaiera de passer une seconde fois un exercice… C’est tout votre système qu’il faudra revoir : modifier le cahier des charges, réécrire le code, refaire les tests unitaires, re livrer en environnement de recette, refaire les tests métier, cela entraînant bien sûr une dérive de délai et de coûts !

Comment éviter le piège ?

Exemple d'alternative à la classe association

Une fois que l’on a posé la question au métier et que l’on a compris qu’un même exercice doit pouvoir être fait plusieurs fois par un même écolier, que faire ? En effet, la classe association ne pouvant pas être utilisée, où mettre les informations de date de passage et de score ?

C’est très simple : le « Passage » reste bel et bien une classe mais :

  • elle sera rattachée à écolier et à exercice,
  • l’association entre écolier et exercice saute.

Cela donnera donc :

  • Un écolier fait aucun ou plusieurs passages et un passage est réalisé par un seul écolier.
  • Un exercice fait l’objet d’aucun ou plusieurs passages et un passage porte sur un seul exercice.

Autrement dit, j’ai cassé la relation avec multiplicité « * » entre écolier et exercice pour faire deux associations et cela exprime parfaitement le fait qu’un écolier puisse passer plusieurs fois le même exercice.

Pourquoi ? Vous demandez-vous peut-être…

Exemple de jeu de données

Tout simplement parce que dans le cas initial, l’identifiant de la classe association était composé des identifiants de l’écolier et de l’exercice, ce qui interdisait les doublons. Alors que dans le cas final, « Passage » étant une classe à part entière, elle a son propre identifiant, complètement indépendant de ceux de l’écolier et de l’exercice. Par conséquent, on peut en créer autant qu’on veut, Nadia peut passer 50 fois l’exercice 1 si elle le souhaite.

Une classe association peut-elle être rattachée à une autre classe ?

Si jamais vous vous posez la question, sachez que la réponse est oui. Au même titre que les autres classes de votre modèle, une classe association peut elle aussi être rattachée à une ou plusieurs autres classes.

Conclusion

Sur le principe, la technique de la classe association est assez simple à acquérir dès lors qu’on a compris la logique qui la sous-tend. Cependant, un usage trop systématique peut être fortement préjudiciable à la solution qui sera développée, aussi je vous recommande fortement de bien toujours penser à poser cette question de « peut-il y en avoir plusieurs ? »

Outre le fait que c’est un questionnement très pertinent pour comprendre le fonctionnement d’un métier et clarifier une attente, il vous permettra de modéliser puis de décrire de façon très précise l’attendu et ainsi éviter une incompréhension qui s’avèrera toujours coûteuse !

Pour en apprendre davantage sur la modélisation des données, vous pouvez également parcourir ces articles : 

https://soscahierdescharges.fr/modeliser-les-donnees-dans-un-cahier-des-charges/

https://soscahierdescharges.fr/diagramme-de-classe-les-bonnes-multiplicites/

https://soscahierdescharges.fr/diagramme-de-classe-7-clefs-pour-etre-compris/

N’hésitez pas à vous abonner à notre newsletter en bas de cette article. Postez un commentaire et venez partager votre expérience sur les sujets en lien avec les cahier des charges !

Tentative de définition d’une classe association

Exemple de classe association

Une « classe association », qu’est-ce que c’est ?

Si vous avez été amené à modéliser des concepts métier (un diagramme de classe au sens UML) ou plus simplement à devoir lire un diagramme de classe, alors la représentation ci-dessus ne vous est peut-être pas inconnue.

Mais que signifie-t-elle réellement ? Comment la lire et quand l’utiliser à bon escient ? Tel est l’objet de cet article qui, je l’espère, vous aidera à mieux comprendre la technique de la classe association.

En modélisation UML des données, une « classe association » est une classe à la jonction de deux autres classes. Elle porte des informations, que l’on appelle « attributs », qui sont en dépendance directe des deux autres classes et qui ne pourraient se mettre ni dans l’une, ni dans l’autre.

Bon, vous me direz qu’avec cela, on n’est pas beaucoup plus avancé. Je vais donc illustrer par des exemples. Je préciserais quand même que cet article s’adresse plutôt à des gens qui savent déjà un peu modéliser. A la fin, je vous donnerai une astuce pour vous passer de l’utilisation d’une classe association. Cela permettra aux plus néophytes de se sortir des situations complexes.

Quand peut-il y avoir une classe association ?

Exemple de classe association

Il ne peut y avoir une classe association que si l’association entre les deux autres classes a de part et d’autre une multiplicité maximum égale à « plusieurs », représentée par le symbole « * ».

Dans l’exemple ci-dessus, il y a bien « * » du côté du concept A et du concept B, il est donc possible de mettre une classe association. Dans tous les autres cas, cela constituerait une erreur de modélisation. Pour information, la valeur de la multiplicité minimum (0 ou 1) n’entre pas en ligne de compte.

En synthèse, voici la liste des cas envisageables :

  • Concept A 0 ou 1..1 —————- 0 ou 1..* Concept B : pas de classe association possible
  • Concept A 0 ou 1..* —————– 0 ou 1..1 Concept B : pas de classe association possible
  • Concept A 0 ou 1..* —————– 0 ou 1..* Concept B : classe association possible

Y a-t-il toujours une classe association ?

Exemple de cas sans classe association

On pourrait penser que dès lors qu’il y a une association entre deux classes avec « * » en multiplicité maximum, alors il y a forcément une classe association. Cela est vrai si l’on se place du point de vue d’un développeur fabriquant sa base de données. Mais lorsqu’on travaille à un niveau conceptuel métier, ce qui est le cas lorsqu’on rédige un cahier des charges, alors cela n’est plus du tout systématique.

Pour illustrer cela, je vais prendre un exemple simple. Imaginons que vous deviez rédiger un cahier des charges pour gérer les traducteurs d’une maison d’édition. Un traducteur peut traduire une à plusieurs (*) langues et une même langue peut être traduite par un à plusieurs (*) traducteurs. Le système à implémenter devra donc permettre de renseigner cela et de dire précisément quel traducteur traduit quelle(s) langue(s).

Exemple d'association many to many

Dit plus clairement, le traducteur François traduit l’anglais et l’espagnol et la traductrice Claire traduit l’anglais et l’allemand. Un traducteur se caractérise par son nom et sa date d’entrée dans la maison d’éditions (ce sont ses attributs) et une langue se caractérise par son nom. Souvenez-vous ce que j’ai écrit plus haut : « une classe association vient porter des informations, que l’on appellera « attributs », qui sont en dépendance directe des deux autres classes« . Dans le cas exposé ici, aucun attribut n’est en dépendance à la fois du traducteur et de la langue : nul besoin de représenter une classe association dans la vision « métier » des choses.

Exemple de cas avec une classe association

Toujours dans le cadre de notre maison d’édition, vous devez à présent gérer le fait qu’un traducteur n’a pas le même niveau de maîtrise pour chacune des langues qu’il pratique. François a l’anglais pour langue maternelle et a un niveau courant en espagnol. Quant à Claire, elle est bilingue sur l’anglais et l’allemand.

Où mettre cette nouvelle information qu’est le « niveau » et qui est très importante pour le métier ? Comment représenter graphiquement le fait que pour chaque occurrence de couple « traducteur – langue », je dois pouvoir indiquer le niveau de maîtrise ?

Option 1

Exemple d'association many to many

Option 1 : je dis que le niveau est un nouvel attribut du traducteur. Problème : le niveau que j’attribuerai au traducteur sera le même pour toutes les langues qu’il traite. Pourquoi ? Parce que l’attribut « niveau » du concept « Traducteur » ne peut prendre qu’une seule valeur à un instant T, donc si je dis que François a un niveau « langue maternelle », cette valeur vaudra pour toutes les langues auxquelles il est rattaché : l’anglais et l’espagnol. Or, au regard de l’énoncé, on sait que cela est faux.

Option 2

Exemple d'association many to many

Option 2 : je mets le niveau sur la langue. Quelques secondes de réflexion suffisent à comprendre que cela n’est pas non plus un choix pertinent.

Option 3

Exemple de classe association

Option 3 : je fais appel à la classe association, que je pourrais appeler « Niveau » et sur laquelle je mettrai l’attribut « libellé », la valeur de ce niveau dépendant à la fois du traducteur et de la langue.

Une fois traduit en termes métier, cette représentation graphique signifie bien que pour chaque couple « Traducteur – Langue », je pourrai renseigner le niveau adéquat.

Ainsi :

  • François – Anglais – Langue maternelle
  • François – Espagnol – Courant
  • Claire – Anglais – Bilingue
  • Claire – Allemand – Bilingue

Le piège derrière la classe association

On pourrait avoir le réflexe de systématiquement utiliser la classe association dès lors que les principes précédents sont respectés : association entre deux classes avec « * » de chaque côté et présence d’au moins un attribut en dépendance directe des deux classes. Ce serait cependant une erreur de ne pas prendre un temps de réflexion pour bien approfondir le sujet.

En effet, la classe association a un signification bien précise et est porteuse d’une contrainte forte que je vais illustrer via un deuxième exemple.

Cas concret

Problématique à résoudre

Vous devez rédiger un cahier des charges pour une plateforme permettant à des écoliers de faire des exercices en ligne. Un écolier peut passer plusieurs exercices et un même exercice peut bien sûr être passé par plusieurs écoliers, ceux d’une même classe par exemple.

Pour chaque passage d’un exercice, le métier a besoin de pouvoir consulter la date de passage ainsi que le score obtenu par l’écolier.

Exemple de classe association

La classe association comme solution « réflexe »

Premier réflexe, naturel : je crée une classe association « Passage » où je vais stocker les deux attributs « date » et « score ».

Cela pourrait donc donner :

  • Nadia – Exercice 1 – 20/05/2021 10h05 – 78%
  • Nadia – Exercice 2 – 20/05/2021 11h01 – 95%
  • Adrien – Exercice 1 – 21/05/2021 08h33 – 80%
  • Adrien – Exercice 2 – 20/05/2021 08h45 – 63%
  • Etc.

A priori, tout va bien. J’enregistre les informations souhaitées et mon système fonctionne. J’ai cependant oublier de poser une question primordiale à mon interlocuteur métier : un écolier peut-il passer plusieurs fois le même exercice ? Par exemple pour le refaire s’il a obtenu un score insuffisant au premier passage.

Ne tombez pas dans le piège de la classe association systématique

Car c’est là le piège de la classe association : cette représentation implique qu’il ne peut pas y avoir deux occurrences d’un même couple de classes ou, pour illustrer avec l’exemple, cela signifie que Nadia ne pourra pas passer plus d’une fois chacun des exercices mis à sa disposition. Un seul passage autorisé pour l’exercice 1, l’exercice 2, etc.

Exemple de jeu de données

Pour bien comprendre cela, il faut se plonger un instant dans la base de données. Que va-t-il se passer lorsque Nadia va réaliser l’exercice 1 ? Le système va automatiquement créer une occurrence de classe association dont l’identifiant sera composé de celui de Nadia (écolière n° 345) et de celui de l’exercice (n° 61). Et comme il ne peut pas exister en base de données deux occurrences de classe ayant le même identifiant, cela signifie bien que le couple « Nadia – Exercice 1 » ne pourra pas être enregistré deux fois.

L’impact métier dans ce cas précis est donc que l’écolier ne peut pas refaire plusieurs fois un même exercice en vue de s’améliorer.

Conséquence du piège

L’une des première choses à faire lorsque vous pensez représenter une classe association, c’est de bien s’assurer auprès du métier qu’il ne peut pas y avoir de répétition (plusieurs occurrences) d’un même couple de classes.

Dans l’exemple de la maison d’édition et des traducteurs, une fois que l’on a indiqué que l’anglais est la langue maternelle de François, cela n’aurait pas de sens de faire ensuite une deuxième occurrence pour dire qu’il est bilingue sur cette même langue. Donc, dans ce cas, la classe association est parfaitement utilisée.

En revanche, dans le cas des écoliers et des exercices, si le métier vous dit qu’il s’agit d’exercices :

  • à passage unique, alors la classe association se justifie pleinement,
  • pouvant être passés plusieurs fois afin de s’entraîner et de progresser, alors la classe association n’est pas la bonne représentation graphique.

Si l’on ne clarifie pas cela au plus tôt avec le métier, l’impact sur le système développé peut être énorme, et surtout très coûteux. En effet, imaginons que vous donniez votre modèle avec la classe association au développeur. Lui comprend normalement très bien la problématique exposée ci-dessus et les fonctionnalités qu’il développera répondront au besoin exprimé par votre schéma.

Je vous laisse réfléchir à la déconvenue du  métier lorsqu’il effectuera la recette et qu’il essaiera de passer une seconde fois un exercice… C’est tout votre système qu’il faudra revoir : modifier le cahier des charges, réécrire le code, refaire les tests unitaires, re livrer en environnement de recette, refaire les tests métier, cela entraînant bien sûr une dérive de délai et de coûts !

Comment éviter le piège ?

Exemple d'alternative à la classe association

Une fois que l’on a posé la question au métier et que l’on a compris qu’un même exercice doit pouvoir être fait plusieurs fois par un même écolier, que faire ? En effet, la classe association ne pouvant pas être utilisée, où mettre les informations de date de passage et de score ?

C’est très simple : le « Passage » reste bel et bien une classe mais :

  • elle sera rattachée à écolier et à exercice,
  • l’association entre écolier et exercice saute.

Cela donnera donc :

  • Un écolier fait aucun ou plusieurs passages et un passage est réalisé par un seul écolier.
  • Un exercice fait l’objet d’aucun ou plusieurs passages et un passage porte sur un seul exercice.

Autrement dit, j’ai cassé la relation avec multiplicité « * » entre écolier et exercice pour faire deux associations et cela exprime parfaitement le fait qu’un écolier puisse passer plusieurs fois le même exercice.

Pourquoi ? Vous demandez-vous peut-être…

Exemple de jeu de données

Tout simplement parce que dans le cas initial, l’identifiant de la classe association était composé des identifiants de l’écolier et de l’exercice, ce qui interdisait les doublons. Alors que dans le cas final, « Passage » étant une classe à part entière, elle a son propre identifiant, complètement indépendant de ceux de l’écolier et de l’exercice. Par conséquent, on peut en créer autant qu’on veut, Nadia peut passer 50 fois l’exercice 1 si elle le souhaite.

Une classe association peut-elle être rattachée à une autre classe ?

Si jamais vous vous posez la question, sachez que la réponse est oui. Au même titre que les autres classes de votre modèle, une classe association peut elle aussi être rattachée à une ou plusieurs autres classes.

Conclusion

Sur le principe, la technique de la classe association est assez simple à acquérir dès lors qu’on a compris la logique qui la sous-tend. Cependant, un usage trop systématique peut être fortement préjudiciable à la solution qui sera développée, aussi je vous recommande fortement de bien toujours penser à poser cette question de « peut-il y en avoir plusieurs ? »

Outre le fait que c’est un questionnement très pertinent pour comprendre le fonctionnement d’un métier et clarifier une attente, il vous permettra de modéliser puis de décrire de façon très précise l’attendu et ainsi éviter une incompréhension qui s’avèrera toujours coûteuse !

Pour en apprendre davantage sur la modélisation des données, vous pouvez également parcourir ces articles : 

https://soscahierdescharges.fr/modeliser-les-donnees-dans-un-cahier-des-charges/

https://soscahierdescharges.fr/diagramme-de-classe-les-bonnes-multiplicites/

https://soscahierdescharges.fr/diagramme-de-classe-7-clefs-pour-etre-compris/

N’hésitez pas à vous abonner à notre newsletter en bas de cette article. Postez un commentaire et venez partager votre expérience sur les sujets en lien avec les cahier des charges !

comprendre le métier

Comprendre le métier ? Suivez le guide

Ce que nous explique notre interlocuteur au cours d’un atelier est obscur pour vous ? Voilà la problématique à laquelle cet article va tenter de répondre, sans dogmatisme mais en vous présentant des techniques qui ont déjà fait leur preuve. Il en existe certainement d’autres, nous comptons donc sur vous pour nous en faire part… 😉

Tout comme une anomalie, plus une incompréhension fonctionnelle est levée tardivement, plus elle coûte cher à prendre en compte.

Constat général : il est normal de ne pas tout comprendre

Tout d’abord, il faut admettre ce postulat de base : nous serons forcément confrontés, au cours de notre carrière, à l’incompréhension. Cela est vrai pour des internes, cela l’est encore plus lorsque l’on fait de la prestation puisque nous sommes amenés à régulièrement changer de mission, donc de domaine métier, de méthode de travail, d’outil, etc.

Ainsi, il faut avoir conscience :

  • qu’il est normal de ne pas toujours tout comprendre,
  • que l’on ne nous tiendra pas rigueur de ne pas comprendre dès lors que nous faisons des efforts pour changer la donne et que nos progrès sont perceptibles.

L’incompréhension se voit

Lorsqu’on est face à une personne et que l’on ne comprend pas ce qu’elle explique, que ce soit totalement ou partiellement, ne nous leurrons pas : elle le sent, c’est ce que l’on appelle l’intelligence émotionnelle. Sans que nous ayons à dire un mot, le langage corporel nous trahit :

  • sourire forcé,
  • voix chevrotante,
  • regard fuyant,
  • tics physiques (jouer avec son stylo par exemple),
  • se réfugier derrière l’écran de l’ordinateur pour prendre convulsivement des notes sans comprendre ce que l’on rédige,
  • poser des questions « bateaux » : « qui fait cela ? », « combien de fois cela arrive ? », « comment vous faites pour… ? ». Souvent inutiles, elles ne masquent pas du tout notre incompréhension.

Bien entendu, si l’on n’a rien compris durant l’entretien, il n’y a aucune raison pour que l’illumination vienne a posteriori, durant la phase de rédaction. Aucun miracle en perspective : le livrable sera médiocre, voire mauvais.

Pour en apprendre plus sur l’intelligence émotionnelle, je vous recommande la lecture de l’ouvrage de Daniel Goleman, dont vous trouverez un résumé ici : https://des-livres-pour-changer-de-vie.com/lintelligence-emotionnelle/

Ne pas avoir peur de dire qu’on ne comprend pas

Je ne sais pas comment vous faisiez durant votre scolarité mais, au cours de la mienne, j’ai constaté que certains élèves n’hésitaient pas à lever la main et interroger le professeur lorsqu’ils n’avaient pas compris une explication. Ce n’est pas pour autant qu’ils étaient considérés comme des incapables et beaucoup d’élèves moins téméraires étaient très contents que la question soit posée.

De là à penser que ces élèves interrogateurs réussissaient mieux leurs contrôles que ceux qui se contentaient d’accepter leurs incompréhensions, il y a un pas que je ne franchirai pas…

Dire qu’on ne comprend pas est une marque de professionnalisme

Par conséquent, pourquoi une chose qui allait de soi à l’école devient-elle problématique dans le milieu professionnel ? A-t-on donc si peur de perdre notre emploi, de manquer une promotion, de se voir refuser une augmentation de salaire parce que l’on questionne ? Notre ego est-il devenu si important pour que l’idée de montrer une faiblesse le hérisse ? Nous n’attendons pourtant pas d’un médecin qu’il diagnostique précisément ce dont nous souffrons uniquement sur la base de ce qu’il observe… Non, le médecin interroge son patient, l’enquêteur interroge le suspect, et pour faire un cahier des charges, nous questionnons notre client. C’est dans l’ordre des choses, cela fait partie du travail et il serait donc non-professionnel de ne pas le faire.

A ce titre, il faut savoir qu’un client se plaint rarement qu’un consultant le questionne, c’est plutôt le contraire qui s’observe. En effet, quel message envoyons-nous lorsque nous ne questionnons pas ? Car notre interlocuteur connaît notre CV, il sait que nous n’avons pas de connaissances dans tel ou tel domaine. Aussi, le fait de ne pas clarifier les choses ne lui fait pas se dire « ce consultant doit être très bon, il comprend tout sans poser une seule question, j’ai fait le bon choix. » Non, il s’inquiétera, n’aura pas confiance. Or, au début, la confiance est l’une des plus choses les plus difficiles à maintenir, elle se perd beaucoup plus vite qu’elle ne se gagne. Alors autant commencer à la conquérir le plus tôt possible, dès les premières minutes d’un échange.

Notre guide SOS : quelles postures adopter quand on ne comprend pas ?

A présent que les bases ont été jetées, intéressons-nous aux postures à adopter lorsqu’on ne comprend pas.

Il faut savoir identifier ce qui pose problème. Ainsi le « flou » possède son cycle de vie :

  • non identifié : je ne comprends pas une chose mais je ne sais même pas encore qu’elle existe,
  • identifié : je suis face à une chose que je ne comprends pas,
  • soumis : j’ai mis en place des mécanismes qui vont me permettre de comprendre,
  • résolu : j’ai fini pas réellement comprendre et je peux le démontrer.

Nous allons laisser de côté le premier état (« non identifié ») pour nous intéresser directement au flou identifié.

1 – Clarifier tout ce qui n’a pas été compris

Il faut comprendre que lorsque l’on rédige un cahier des charges, on peut être victime du syndrome de la page blanche ou, de la question blanche : on est « sec », on ne sait pas quelles questions poser, un long blanc s’installe… Pour cela, le flou est du pain béni : c’est une source de questions qui va venir alimenter sans effort l’interview, une pépite à transformer.

Cas d’application. Votre interlocuteur vous transmet les informations suivantes :

« Nous voulons moderniser le système de gestion des règlements client. Il faut pouvoir indiquer au niveau d’un client un délai de règlement.

Nous avons besoin de pouvoir rapprocher les règlements constatés en banque avec les factures émises, comme ça nous pourrons identifier les factures non encore réglées.

On doit tracer toutes les actions de relance avec les réponses apportées par les clients. On veut pouvoir catégoriser les clients selon qu’ils sont bons payeurs, payeurs moyens ou très mauvais payeurs. En effet, on veut pouvoir blacklister des clients : avec certains ne plus renouveler de commandes et avec d’autres interrompre les contrats en cours. »

A titre personnel, beaucoup d’éléments me semblent obscurs : les délais de règlement, les actions de relance, les réponses apportées, même « commande », dans ce contexte, me donne des frissons. Alors comment faire en sorte que chacun de ces flous deviennent individuellement limpides et que tout fasse sens ?

Le sujet portant sur la gestion des règlements client, il semble judicieux de commencer par clarifier cela. Qu’est-ce qu’un client au sein de l’organisme ? Y a-t-il une typologie client ? Peut-on obtenir des exemples de client ?

Posez un « nuage de mots » pour visualiser les difficultés.

Le sujet portant sur la gestion des règlements client, il semble judicieux de commencer par clarifier cela. Qu’est-ce qu’un client au sein de l’organisme ? Y a-t-il une typologie client ? Peut-on obtenir des exemples de client ?

Si l’on reformule notre compréhension de ce qu’est un client en intégrant les exemples collectés et que notre interlocuteur acquiesce explicitement, c’est gagné : nous venons de chasser notre premier flou ! Il en reste encore beaucoup mais, au moins, nous avons une base solide sur laquelle avancer.

2 – Avoir un fil directeur (conducteur) pour comprendre pas à pas

Ensuite, c’est le principe de la pelote de laine : on tire le fil et on voit où cela nous mène. Pour cela, l’approche par l’exemple reste une valeur sûre.

Nous vous proposons ci-dessous un exemple de dialogue :

  • A. : « Si j’étais client chez vous, que pourrais-je faire ? Vous m’avez parlé de commande… »
  • Métier : « Oui, les clients nous passent des commandes »
  • A. : « Donc en tant que client, je peux vous passer plusieurs commandes j’imagine. Mais est-ce qu’une commande est passée par un seul client, moi en l’occurrence ? Ou est-ce qu’une commande peut être groupée, c’est-à-dire que je la partage avec un autre client par exemple ? »
  • Métier : « Non, la commande est passée par un seul client. »
  • A. : « C’est très clair. Est-ce que je peux en déduire qu’un règlement, le paiement donc, concerne une commande ? Peut-on régler plusieurs commandes avec un seul règlement ? »
  • Etc.

On le voit, l’idée est donc d’avancer pas à pas, par couple de concepts métier, sans se précipiter. Et tant qu’un couple n’est pas parfaitement compris, on ne change pas de sujet.

3 – IMPORTANT Contrôler que l’on a bien compris

Comment savoir si j’ai bien compris ?

  • une définition illustre chaque concept,
  • il y a au moins un exemple par concept,
  • j’ai reformulé le fonctionnement de ce couple de concepts et mon interlocuteur a validé intégralement ma compréhension.

Et si vous êtes chevronné vérifiez aussi :

  • que pour une association entre deux concepts, les quatre multiplicités sont présentes,
  • qu’un exemple clarifie les multiplicités les plus complexes, structurantes.

4 – Demander à voir concrètement les choses pour être sûr de comprendre

Un dernier point qui fonctionne bien si l’on travaille sur une application existante :  demander à son interlocuteur qu’il nous montre concrètement les choses. Cela est particulièrement efficace si nous n’avons pas les habilitations nécessaires pour aller voir par nous-mêmes (par exemple lorsqu’une évolution concerne des fonctionnalités d’administrateur et que vous ne l’êtes pas.)

J’espère que ces conseils vous seront utiles et vous aideront à entrer plus facilement dans un sujet complexe tout en conservant votre confiance en vous. N’hésitez pas à lire l’article suivant, qui vous éclairera également sur le sujet : https://soscahierdescharges.fr/modeliser-les-donnees-dans-un-cahier-des-charges/

N’hésitez pas à vous abonner à notre newsletter en bas de cette article. Postez un commentaire et venez partager votre expérience sur les sujets en lien avec les cahier des charges !

Faire un sommaire correct en 7 clefs simples et efficaces

Faire efficacement un sommaire
Faire un sommaire efficacement, avoir en un seul coup d’œil la vision complète du contenu du document

Quel intérêt à soigner son sommaire ?

Parce que le sommaire, autrement appelé « table des matières », est la première chose que lit un commanditaire lorsqu’il ouvre votre cahier des charges (après la page de garde j’entends), il est primordial d’en soigner la présentation.

Continuer la lecture de Faire un sommaire correct en 7 clefs simples et efficaces

Cas élémentaire de modélisation des concepts métier

Vous ne savez pas comment démarrer un cahier des charges ? Voici un cas élémentaire de modélisation des concepts métier. Fiabilisation projet 100% garantie 😉

Continuer la lecture de Cas élémentaire de modélisation des concepts métier

Les productions d’un cahier des charges

L’efficacité d’un recueil du besoin dans le cadre d’un cahier des charges ou autre (EB, SFD, Epic, US, Feature) s’évalue en partie au regard du nombre des 4 « productions » clés qu’il a permis de collecter. C’est la collecte de ces productions qui va guider le questionnement, ceci ayant pour effet bénéfique d’augmenter le nombre de questions utiles et de garantir  vos résultats.

Continuer la lecture de Les productions d’un cahier des charges

Critères qualité du recueil des besoins

Objectiver par des critères simples la qualité de votre recueil des besoins ? Rendre compte comme un pro ? Rattraper l’inefficacité d’un interview ? Voici des critères tangibles et quantifiables. Ceux-ci devraient sans équivoque vous aider à sortir du pur ressenti post atelier  :

  • « Cela s’est plutôt bien passé, je suis content(e) » 
  • « Le métier trouve que je ne les comprends jamais » 
  • « J’ai été catastrophique, je n’ai rien compris »
  • « Je n’ai pas eu le temps de tout recueillir »…

pour passer à une analyse factuelle de votre efficience. Bref, de quoi vous protéger des éventuels ressentis de vos commanditaires, représentants métier et ainsi être serein sur vos performances projet.

Continuer la lecture de Critères qualité du recueil des besoins

L’outil que je devrais garder secret… pour fabriquer mes cahiers des charges

Aujourd’hui, je vous propose un article un peu spécial. Je vais vous parler, ou plutôt vous présenter sous forme de vidéo, un outil que je devrais garder secret et que j’utilise quasi quotidiennement pour fabriquer mes cahiers des charges. Il booste ma productivité, c’est BA.autoconcept.

Continuer la lecture de L’outil que je devrais garder secret… pour fabriquer mes cahiers des charges

Avoir une prise de notes efficace : quelques fondamentaux (partie 1)

Avant de nous intéresser à la prise de notes en elle-même, tant en termes de forme que de fond et qui fera l’objet d’un second article, il nous semble important d’énoncer quelques principes de base qui conditionnent fortement la qualité de ce que l’on rédige au cours d’un entretien.

Quelques pré-requis clés à la prise de notes

Etre concentré

Tout d’abord, il s’agit d’être totalement concentré sur les propos de son interlocuteur, d’être investi à 100% dans l’échange et d’être pleinement conscient que l’autre va nous communiquer des messages importants.

Sans cet effort de concentration, nous risquons de passer à côté d’informations clés ou de les déformer lors de leur transcription.

Continuer la lecture de Avoir une prise de notes efficace : quelques fondamentaux (partie 1)