QUESTIONS & RÉPONSES La collection de Solve DSI - Yann-Eric Devars
← Revenir aux réponses

Que faut-il savoir sur « Méthode, comment construire ce schéma en atelier » ?

Extrait de Cartographie du système d’information

Vous allez maintenant apprendre une méthode reproductible. Elle est compatible avec une démarche top down, mais elle peut être utilisée depuis n’importe quelle couche si vous savez remonter méthodiquement.

L’atelier se déroule en six étapes. Ne sautez pas d’étapes, les personnes qui dessinent directement font des cartes instables, parce qu’ils n’ont pas stabilisé le vocabulaire et la responsabilité.

Étape 1 — Nommer le fluxVous devez donner un nom au flux, un nom qui se comprend dans l’entreprise, évitez les noms techniques, évitez aussi les noms trop génériques : « Flux client » ne veut rien dire, « Transmission des commandes validées vers la facturation » est déjà mieux.

Vous pouvez aussi numéroter vos flux, non pas pour faire joli, mais pour les référencer dans la documentation et les analyses d’impact. Les identifiants sont indispensables dès que vous voulez requêter et relier des éléments.

Étape 2 — Identifier les deux métiersVous devez fixer qui est Métier A et qui est Métier B, ne laissez pas cela flou, il faut une responsabilité, sinon personne ne pourra valider la carte (étape nécessaire dans la méthode DYNAMAP).

Étape 3 — Identifier le logiciel médiateurVous devez nommer le logiciel, si l’organisation utilise une CMDB ou un inventaire applicatif, utilisez l’identifiant de référence, et mettez le nom métier en libellé. Vous devez éviter les confusions du type on a deux outils qui s’appellent pareil.

Si l’outil est SaaS, vous devez déjà vous demander si la dépendance à un fournisseur est vitale, et si vous devez la faire apparaître sur la carte ou dans la documentation associée, vous le faites déjà dans d’autres représentations, vous devez garder la discipline ici aussi.

Étape 4 — Identifier la base de données requêtéeLe schéma montre explicitement une base de données, ceci oblige à répondre à une question simple, où vivent les données. Dans un SaaS, la base peut être cachée et non accessible, peu importe, elle existe quand même : vous pouvez donc la représenter comme Base de données du fournisseur si vous n’avez pas l’accès direct, mais vous devez l’afficher, car c’est une dépendance.

Étape 5 — Décrire les données qui transitent sur chaque flèche Ici, vous travaillez avec les métiers, pas contre eux, vous n’avez pas besoin d’un dictionnaire complet, vous devez identifier les paquets d’information.

Par exemple.

Identité client, commande, conditions tarifaires, remise, date de livraison, statut, référence contrat.

Écriture comptable, TVA, référence facture, pièce justificative, statut de paiement.

Ticket, catégorie, priorité, description, pièce jointe, statut de résolution.

Vous ne cherchez pas l’exhaustivité, vous cherchez à décrire ce qui est utile à comprendre l’impact. La règle est simple, si la donnée a un impact sur une décision, une obligation, un risque, ou un coût, vous devez la citer sinon, elle ira dans le dictionnaire de données, pas sur la carte et c’est justement ce que l’on veut éviter.

Étape 6 — Qualifier la criticité et rendre la convention visibleVous devez maintenant apposer la criticité sur les flèches, la criticité doit être discutée, assumée, et validée et surtout, elle doit être stable.

Une erreur fréquente consiste à mettre critique partout, par réflexe de prudence : c’est une erreur de gouvernance, une cartographie où tout est critique est une cartographie illisible et surtout inéficace, parce qu’elle ne permet plus de prioriser.