Réponse.

Histoire de la question :

Dans les projets classiques, des conflits surviennent souvent entre les analystes et les architectes, ainsi qu'entre les analystes systèmes et les analystes métiers : chacun essaie de "capturer" ou, au contraire, de déléguer une partie de ses responsabilités. Une définition claire des limites est devenue l'un des signes d'une équipe mature.

Problème :

Le danger réside dans le chevauchement et la duplication des travaux, ce qui entraîne des malentendus, une perte de responsabilité, des retards, et dans certains cas, une réalisation parallèle et contradictoire de la même partie du système.

Solution :

Définir les artéfacts et produits finaux pour chaque rôle (par exemple : l’analyste métier est responsable des objectifs métiers, l’analyste système — des spécifications fonctionnelles, l’architecte — des solutions architecturales)
Au début du projet, organiser des ateliers/réunions avec une clarification claire des zones de responsabilité et une approbation des documents réglementaires (par exemple, des matrices RACI)
Il est important de discuter et de corriger régulièrement les limites au fur et à mesure de l'évolution du projet et du changement de contexte

Caractéristiques clés :

Répartition transparente des rôles et des zones de responsabilité
Définition claire des artéfacts et des points d'entrée/sortie entre eux
Communication constante et contrôle des interfaces entre les tâches

Questions pièges.

L'analyste système doit-il intervenir au niveau de la conception de l'architecture du système entier ?

Non, l'architecte est responsable des décisions architecturales. L'analyste précise les exigences que l'architecte peut utiliser, mais ne conçoit pas l'architecture dans son ensemble.

L'analyste métier peut-il s'occuper directement de la description des contraintes techniques ?

En général, non — l'analyste métier élabore des exigences métier. Les contraintes techniques relèvent de la responsabilité de l'analyste système ou de l'architecte.

Si la description de la tâche a été fournie par l'analyste métier, l'analyste système doit-il dupliquer la réunion avec l'entreprise ?

Non, mais l'analyste système doit s'assurer qu'il a bien compris et, en cas de divergences, soulever des questions.

Erreurs typiques et anti-patters

Délégation par défaut des zones de responsabilité
Description floue des produits finaux (artéfacts)
Conflits dus à l'absence de communication régulière entre les rôles

Exemple de la vie

Cas négatif :

Deux équipes ont travaillé parallèlement sur une même partie du système : les analystes rédigeaient une pseudo-architecture, tandis que les architectes décrivaient des processus métiers. Au final, les spécifications divergeaient et la mise en œuvre était retardée.

Avantages :

Tentative d'accélérer le travail

Inconvénients :

Duplication, divergence des documents, perte de délais

Cas positif :

Atelier collaboratif au début, où ils ont convenu de qui était responsable de quoi, documenté les limites et les interfaces. Par la suite, à chaque étape, des révisions de ces accords étaient réalisées.