Vous devez concevoir une nouvelle solution pour un système IT complexe. Quels sont vos prochains pas ?
Avant de commencer à élaborer un plan d’action, il est essentiel de rassembler toutes les meilleures pratiques des managers et des experts dans une structure compréhensible (même partiellement).
Dans l’exemple ci-dessous, une diagramme illustre que, dans tout projet, il doit toujours exister un facteur central, le premier « briquet » qui déterminera le format de tout le travail.
Dans le développement logiciel, je propose de prendre en tant que « briquet » le serveur GitLab ou GitHub, ainsi que le format Markdown pour la documentation, située dans un seul endroit et considérée comme du code à manipuler. Je recommande de ne jamais changer cela, car la documentation est, dans tout projet, votre tout (à ce sujet, nous ne reviendrons plus - c’est une convention).
Le risque d’obsolétisation de la documentation au cours du développement ou de l’évolution du produit dans ce modèle est minimal. Les principales causes d’obsolétisation :
- La documentation n’est jamais mise à jour.
- La documentation est dispersée, rendant impossible de rassembler une version complète et actualisée à partir de fragments.
Ces deux facteurs sont contrôlés dans ce modèle.
Dans certaines équipes, il existe la possibilité d’émergence d’un « community » où chaque membre peut contribuer librement à la documentation.
Trois forces doivent avancer en parallèle : l’architecte, le spécialiste et le curateur du projet.
Le spécialiste doit réaliser les tâches définies par l’architecte. Les spécialistes de différents niveaux trouvent eux-mêmes les solutions. L’architecte fixe le format de description du projet. Le curateur du projet s’occupe des rôles et des règles pour assurer un déroulement fluide, prévisible et, autant que possible, confortable.
Sans une communication claire des zones de responsabilité, tant du côté du développeur que du client, le travail sera inefficace.
Ce sujet introduit la notion de Gemba — une approche japonaise de suivi des processus de travail.
Pour commencer un projet de grande envergure, il faut d’abord établir une vue d’ensemble (rappelons que le « briquet » git+markdown a été posé précédemment). Elle permet de communiquer sur un même langage à tous les participants et d’éviter les malentendus et les explications sur les doigts.
À chaque étape, des membres de différents domaines et spécialités sont impliqués.
Un modèle courant parmi les clients est la visualisation de l’architecture logicielle selon la « C4 Model » (Contexte, Conteneurs, Composants, Code) et ses variantes.
Les diagrammes de différents niveaux de détail sont conçus différemment, ce qui les rend compréhensibles aussi bien pour les techniciens que pour les non-techniciens.
Dans mon travail, j’utilise :
High Level Design — un diagramme montrant les équipements réseau et les contours. Il inclut le pare-feu et les moyens de protection. Les flux de données sont représentés, en marquant la localisation des données sensibles. Les composants sont reliés par des lignes sans flèches, avec indication des ports et protocoles.
À partir de ce diagramme, on crée un diagramme de déploiement (sans exemple), où l’on ajoute :
- la plateforme de virtualisation
- les noms et versions du système d’exploitation et de la base de données
- les conteneurs et l’orchestrateur
- les exigences matérielles
- la liaison avec le fournisseur d’équipement
- l’environnement de déploiement
Ce diagramme permet de comprendre comment la solution est déployée et maintenue. Comment elle est évoluée et mise à l’échelle. Comment les tâches régulières sont effectuées, ainsi que les sauvegardes et restaurations.
Enfin, on établit un diagramme conteneur, où sont indiqués les serveurs (comme services), les services, les microservices, décrit l’IaaS, les interfaces, les protocoles de communication, les types d’intégration, les bases de données, les brokers de messages, les bus, les passerelles, la synchronisation des échanges et le type d’interaction (XML, API, fichiers).
(Dernier diagramme, Diagramme des classes, utilisé selon le choix — optionnel.)> En détaillant les composants de chaque diagramme étape par étape, le curateur et l’architecte comprennent quelles tâches émergent et comment elles doivent être réparties entre les participants. Le diagramme des étapes permet à chaque participant de voir où il en est et quel est son prochain pas.
Télécharger le diagramme Mermaid : flow_new_arch.md (2,5 Ko)
flowchart TD
classDef pclass fill:#f5f5dc
classDef wclass fill:#f96
classDef pmclass fill:#4f7
classDef yclass fill:#ff9
classDef oclass fill:#ffbf00
classDef gclass fill:#c5e384
a((Début)):::gclass --1-->
b( Carte de solution<br><i>dans le projet Gitlab<br>format Markdown</i>):::wclass -->
q{ } -.2.->
g[Processus] --3-->
h[Réglementations] --4-->
i[Zones de responsabilité] -.->
p
g -->
s( Schéma d'interaction des personnes sur le projet, en tenant compte des types de tâches et de leur séquence ):::pclass
h -->
t( Exigences à respecter : codage, revue, présentation, communication, ordre, culture, conformité ):::pclass
i -->
u( Précision dans l'affectation et l'exécution des tâches, fluidité dans la collaboration ):::pclass
q --5-->
c(HLD-diagramme):::oclass --6-->
d(Diagramme de déploiement):::oclass --7-->
e(Diagramme conteneur) :::oclass --8-->
p(Documents en ligne):::yclass -->
j[[Solution technique]]:::pmclass
c --> k( Réseaux, distribution des conteneurs, MSÉ et éléments de sécurité, méthodes de connexion à l'assistance technique ):::pclass
c --> o( Flux de données clés, localisation des données sensibles selon leur type : données personnelles, secrets commerciaux, etc. ):::pclass
d --> m( Exigences concernant le matériel, l'équipement, la performance, lien avec le fournisseur, virtualisation, conteneurisation, orchestration, environnement de déploiement ):::pclass
e --> n( Serveurs comme service, services, IaaS, microservices, interfaces, protocoles et types d'intégration, bases de données, brokers, composants externes, intégrations : bus, files d'attente, passerelles, type de liaison sync/async, protocoles d'interaction ):::pclass
Suivez toujours les blocs du diagramme. Identifiez les correspondances et organisez votre travail de manière à éviter les blancs. Si des modifications du processus sont nécessaires, apportez-les progressivement.