En parallèle de la définition des architectures boîte noire et boîte blanche, l’architecte doit identifier les interfaces, externes et internes (avec les systèmes extérieurs, entre les fonctions du système et entre ses composants).
Tout comme il doit s’assurer que chaque fonction et chaque composant est porté en responsabilité par un rôle, de même il doit mettre sous contrôle l’ensemble des interfaces identifiées.
La complexité d’un système est en autre, liée au nombre de ses interfaces qui peut conditionner le nombre de parties prenantes à impliquer. La gestion des interfaces (humaines, physiques, logicielles…) est une activité clef de la maîtrise des risques sur un projet. Dans la partie boîte noire, la définition des interfaces est un élément majeur dans la formalisation du périmètre d’étude et l’intégration du système dans son environnement.
Parmi les principaux écueils, on notera :
- Identifier des interfaces externes sans se poser la question du besoin qu’on doit couvrir et aller trop vite dans le détail technique (ex : vouloir définir finement les types de données à faire transiter). C’est souvent amplifié par une volonté de re-use mal cadrée par rapport au nouveau contexte/besoin.
- Ne pas suivre en maturité les interfaces, c’est à dire ne pas gérer une interface car encore peu mature (cela met les gens en attente et génère des retards potentiels) et/ou ne pas anticiper le fait que la définition de certaines interfaces va évoluer (ce qui génère un rework perçu comme inutile).
- Mettre à jour les interfaces sans informer les parties prenantes impactées par cette modification.
- Ne pas identifier de responsabilité pour une interface.
- Mal gérer en configuration les deux organes de part et d’autre lors de l’intégration des interfaces.
- Interfaces bien définies sur des aspects précis (ex : fonctionnement statique mécanique) qui permettent à priori l’intégration mais qui sont mal définies au final sur d’autres aspects (ex : fonctionnement en dynamique).
- Détourner des interfaces (dans le cadre d’un re-use) et risquer de sortir du nominal de design de l’interface (avec des problématiques associées, ce qui reviendrait plus cher que de définir la bonne interface).
- Une mauvaise définition des interfaces externes conduisant à une ambiguïté sur le périmètre (ex : l’interface pour authentifier l’utilisateur : le client considère que c’est dedans et le concepteur du logiciel considère que c’est hors de son périmètre).
Voici quelques bonnes pratiques à prendre en compte :
- Utiliser l’architecture pour identifier les interfaces.
- S’assurer que chaque interface est bien portée (en responsabilité).
- Mettre en place un processus de gestion de maturité des interfaces.
- Dans le cadre de re-use se reposer la question du besoin auquel on répond avec chaque interface.
- Mettre des détrompeurs (Poka-Yoke) sur des interfaces qui sont physiquement identiques mais fonctionnellement différentes (ex : détrompeur sur les prises murales vides et oxygène dans les chambres d’hôpital).
- Définir toutes les caractéristiques de l’interface (le nominal et la robustesse lorsqu’on sort du nominal).
- Utiliser du MBSE pour définir de façon la plus exhaustive possible toutes les interfaces.
- Standardiser la manière de définir les interfaces.
- S’appuyer sur la maîtrise des interfaces pour optimiser les interactions avec les parties prenantes (ex : la gestion de plusieurs interfaces avec une même partie prenante peut permettre d’augmenter la communalisation entre ces interfaces).
Nous avons compilé ici un certain nombre de verbatims de chef de projet ou d’architecte système de différentes entreprises, et qui font écho à cette phase :
“ Nous avons mis en place un processus de gestion de maturité des interfaces, en particulier sur le suivi des interfaces mécaniques. Chaque document d’interface a un niveau de maturité défini et affiché, ce qui permet de partager les risques associés à chaque interface.
“Sur des systèmes logiciels, nous procédons à de l’early-integration plutôt qu’à une montée progressive en maturité des interfaces. (Attention néanmoins à ce que cette pratique ne se couple pas à l’écueil mentionné au-dessus sur le questionnement du besoin à couvrir).
“ Pour le hardware : on est plutôt sur la mise en place d’une étape d’intégration virtuelle (intégration des modèles numériques métier – 3D, hydrauliques, électriques…) pour anticiper les problèmes d’intégration.
“Mise en place d’une gestion outillée des interfaces en utilisant le cadre CESAM dans Xatis (Safran).
Vos commentaires seront étudiés par les membres du Cercle lors de la prochaine réunion mensuelle.