Réponse.

Histoire de la question :

Dans les projets classiques et agiles, les exigences relatives aux artefacts d'analyse diffèrent : certains nécessitent des spécifications détaillées et des diagrammes de classes, d'autres se contentent de tableaux ou de croquis simples. De nombreuses organisations ont leurs propres modèles, mais l'utilité réelle de la documentation est déterminée par sa pertinence et son applicabilité.

Problème :

L'absence d'un ensemble standard d'artefacts conduit à la confusion (« que dessiner quand ? »), et leur excès à de la bureaucratie et à une documentation obsolète, non utilisée par l'équipe. Souvent, les analystes créent des artefacts « juste pour la galerie » sans consultation avec les développeurs et les testeurs.

Solution :

Un analyste système compétent :

Organise des réunions de lancement avec l'équipe et le client, identifie leurs douleurs et les formats d'artefacts adaptés.
Forme une matrice de responsabilité (RACI) pour la documentation : qui a besoin de quel artefact, qui le maintient et à quel stade.
En collaboration avec l'architecte et les leads, s'accorde sur l'utilisation des diagrammes de classes (pour une logique complexe) ou d'un processus BPMN ou d'un mockup.
Précise et révise constamment l'ensemble des artefacts au fur et à mesure du projet — la pertinence prime sur la complétude.

Caractéristiques clés :

Il n'existe pas d'ensemble universel d'artefacts : différents projets nécessitent différents documents.
La communication et l'accord collectif sont la clé du succès (partage de responsabilité).
Chaque artefact doit résoudre une tâche spécifique, être vivant et maintenu.

Questions pièges.

Peut-on utiliser un seul type de diagramme (par exemple, uniquement BPMN) pour toutes les situations ?

Non, chaque type de diagramme ou document révèle un aspect différent du système : BPMN pour les processus, UML pour les objets et les interactions, tableaux pour les référentiels. Les combiner est la meilleure pratique.

Un document de spécification détaillé est-il toujours nécessaire ?

Pas nécessairement. Dans des startups, des pilotes, ou des projets agiles, des documents légers basés sur le backlog peuvent suffire — l'essentiel est que l'équipe comprenne les tâches.

Un analyste peut-il exiger que l'équipe suive son modèle de documentation ?

Non. Les formats et modèles de documentation doivent émerger au cours de discussions et d'accords avec l'équipe et le client, et être pratiques pour tous les participants.

Erreurs typiques et anti-modèles

Copier mécaniquement l'ensemble des documents d'autres projets.
Créer des documentations « pour le principe ».
Ignorer le feedback de l'équipe et refuser de travailler avec des artefacts pertinents.

Exemple dans la vie réelle

Cas négatif : Un analyste système a mis en place 6 diagrammes différents pour chaque processus dans le cadre d'un projet d'entreprise. L'équipe s'est étouffée dans la documentation, personne ne la lisait, et ils travaillaient à partir de tâches orales.

Avantages :

Volonté de formaliser le système à un niveau élevé.

Inconvénients :

Perte de temps, confusion.
Documentation peu fiable au moment de la mise en œuvre.

Cas positif : Dans un autre projet, l'analyste a enregistré uniquement un schéma BPMN et un court tableau d'attributs, qu'il a régulièrement précisés et actualisés suite aux rencontres avec les développeurs.