Architecture système

https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme

Inititation

Principe généraliste

Un architecte, c’est avant tout le dépositaire d’une méthode et d’une vision.

• La méthode permet d’analyser un système selon tous ses axes et surtout de poser les bonnes questions.
• La vision est le fruit d’une réflexion en commun entre les experts des différents composants et l’architecte. Elle constitue la façon optimale d’organiser les composants entre eux afin d’en obtenir la meilleure efficacité globale : c’est l’architecture cible.

On part toujours d'un besoin, on pose des questions et on mène une étude.

Caractéristiques d'une bonne architecture

Elle répond à plusieurs caractéristiques:

• La sécurité : Elle s'appuie sur la disponibilité, l'intégrité, la confidentialité, la traçabilité (DICT) ; ainsi qu'une perte de données maximale admissible.
• L'élasticité (scalabilité) : le système doit pouvoir répondre à des contraintes changeantes. On parle d'élasticité verticale quand on rajoute des ressources (RAM, CPU, etc) et horizontale quand on rajoute des nouveaux éléments (serveurs web, etc).
• Le couplage faible : le couplage est la nature de l'adhérence qu'ont deux systèmes entre eux. Une architecture moderne et bien pensée a une adhérence faible avec ses interfaces externes et internes. L'idée est que si deux services ont un couplage faible : un changement de l'un n'entraînera pas tellement de changements sur l'autre. C'est l'un des buts de l'approche micro-services, par ex. Autre exemple : mettre le nom du PDG devant sa place de parking est un couplage fort, mettre sa fonction (PDG) est un couplage faible qui permet de changer le PDG sans changer la plaque...
• La simplicité : un système simple est compréhensible, et donc plus stable dans la durée.

Représentation de l'architecture

[On nous explique qu'il faut faire des schémas d'architecture, waouh] Que représenter ? Un Si vu sous l'angle de l'architecture technique peut se décomposer en 4 plans :

• Fonctionnel : représente l'aspect métier, que fait l'application et la nature des données qu'elle échange avec le reste du monde
• Le plan applicatif : les flux (protocole, fréquence, sens), les stocks (partage de donnée...), les middlewares (base de données, serveur java…) et les frameworks utilisés (.NET, Java...)
• Le plan infrastructure permet de décrire les choix techniques (serveurs choisis, connexions réseau, etc)
• La couche opérationnelle décrit la gestion du système : mécanismes de sauvegarde, de supervision, de métrologie, etc

Description des 4 couches

Couche fonctionnelle

Quel que soit le projet, la méthode devrait toujours être appliquée.

Donc, la couche fonctionnelle ? Elle traite de tout ce que fait l'application : les données manipulées, et comment elle s'inscrit dans son écosystème applicatif. On part toujours d'un besoin et on mène une étude : le questionnement des besoins est essentiel. Il faut aussi voir les ambitions du système dans le temps (combien d'utilisateurs au final ?) et dans l'organisation (on peut commencer par ne gérer que la paye, et finir avec un soft pour toute la RH). Il faut éviter de se jeter sur la résolution de problème sans faire d'étude fonctionnelle : plus on évite l’analyse fonctionnelle, plus le système défini risque d’être inadapté au besoins réels des utilisateurs. Il faut réussir à prendre du recul pour voir le tableau global. L'analyse fonctionnelle étudie quatre aspects :

• Les utilisateurs
• Les données
• Les traitements
• Les interfaces applicatives

Identifier les utilisateurs

On commence par identifier simplement les utilisateurs. As-t'on une gestion des habilitations ? Est-ce que des partenaires vont intervenir ? Aura-t'on des clients depuis le net ? Dans quels fuseaux horaires ? La volumétrie est très importante à évaluer aussi. Combien au total, en même temps ? Y'a-t'il des populations clefs à prendre en compte ? Des gens en lecture seule ? En gros, on s'intéresse à l'usage.

Analyser les données

Il s'agit d'analyser les données qui seront traitées par le système. Une fois les utilisateurs bien identifiés, on peut commencer à s'intéresser aux données qui sont manipulées : D’où viennent-elles ? Quelle est leur sensibilité (confidentialité) ? Sur quels référentiels s’appuient-elles ? Quel est leur cycle de vie : qui les produit, qui les transforme, qui les consomme ? Quel est leur format ? Quel est leur niveau de qualité ? Ces informations sont importantes en terme de sécurité, mais aussi en terme de référentiel de données.

Si on considère une application traitant l’inventaire magasin de boîtes de petits pois (leur nombre, leur prix, leur emplacement en rayon) qui doit s’interfacer avec l’application gérant l'entrepôt, on doit particulièrement s’assurer que la notion de « boîte de petit pois » est la même partout. Plus d’une fois, on se rendra compte que côté entrepôt, on gère seulement des palettes de boîtes et qu’un traitement est nécessaire pour passer d’un système à un autre.

Les traitements

On sait qui utilise le système et quelles sont les données, alors maintenant, on en fait quoi ? Ici, il est question de lister les grands blocs fonctionnels par type d’usage : gestion d’inventaire, authentification des utilisateurs, production de rapports... Idéalement, c’est ici qu’on va associer des notions de performances : telle fonction doit répondre en moins de 3 secondes, tel rapport doit être produit chaque nuit, etc. Dans la plupart des projets, personne n’est capable de fournir ces indications de manière explicite et immédiate. C’est souvent une fois le projet déployé qu’il faut revenir à cette étape et détailler, en s’appuyant sur les premiers retours utilisateurs. En première instance, un simple gros bloc peut tout à fait faire l’affaire, permettant de représenter la cible ou la destination des échanges avec les autres applications.

Identifier les interfaces

Qui produit la donnée, qui sont les consommateurs ? Les échanges entre les systèmes doivent être caractérisés par 2 éléments :

• La donnée portée
• Le sens de transfert

On ne se demande pas qui initie quoi (ça c'est la couche logique), mais quelles sont applications source et cible. Comprendre les flux permet de s'interroger sur le fonctionnement global. Cela permet aussi d'identifier les problématiques structurelles (connexions, volumétries...) et d'anticiper des problèmes techniques.

Couche applicative (ou logique, ou composant)

L'objectif fonctionnel étant identifié, on peut regarder comment applicativement, le système va répondre aux besoins. Ici, on va plutôt adresser nos questions aux développeurs et aux experts des différents middleware. Il s'agit de décrire principalement :

• Les flux : protocole, fq, sens
• Les gisements de données : types, volumes
• Les middlewares : bdd, java, composant d'authent
• Les frameworks de developpement utilisés

Attention, lors des choix, à prendre en compte l'exploit :)

• Qui va être en charge du composant ?
• Les équipes cibles peuvent-elles assurer les plages horaires de service ?
• Comment avoir de l'expertise en cas de besoin ?

Le principe au niveau de la couche applicative est d'instancier les éléments de l'analyse fonctionnelle:

• À quels flux techniques correspond un flux métier ?
• Dans quelle base sera stockée la donnée ?
• Dans quel serveur d'application porte le traitement identifié ?

On peut aussi faire apparaître des briques de sécurité pour répondre aux contraintes DICT, comme un WAF par exemple, et les zones réseau.

Identifier les flux

Les flux sont une des composantes les plus importantes en architecture sys, notamment avec l'émergence du cloud. En s'appuyant sur l'analyse autour des interfaces on peut ici zoomer sur les apects techniques:

• Le protocole réseau (UDP, TCP, et protocole applicatif comme SMB, HTTP, etc)
• Sens de l'initialisation du flux (pour les fw)
• Volumétrie transmise, globale et unitaire
• Fréquence d'envoi
• Temps imposé entre la réception du flux et la restitution du résultat
• Zones réseau traversées.

Il est important d'identifier les zones de sécurité traversées (DMZ, BCK, etc) : tous les flux ne seront pas possible en fonction de la politique de sécurité. Les identifier est surtout une question de connaissances personnelles et d'expérience. L'expérience permet de porter un regard sur les contraintes et de les identifier. Certains protocoles peuvent par exemple répondre à certaines contraintes de confidentialité avec du chiffrement. Cela peut sembler évident, mais l'agilité amène une tendance à se précipiter. Il faut systématiquement mettre en avant les besoins pour s'assurer que l'on y répond systématiquement : la méthode, c'est tout le temps !

En ce qui concerne les flux, il faut aussi penser à évaluer leur performances et leur capacité ; en évaluant bien les contraintes de volume et de fq, on peut estimer le débit et la latence nécessaires.

Gisements de données

Ici aussi, on s'appuie sur l'analyse fonctionnelle.

• Quelles sont les données à garder—Faut-il en filtrer une partie ?
• Dans quel format ?—Fichier ? Base de données SQL ? NoSQL ?
• Pendant combien de temps ?—et quelle sera la politique de purge ?
• Qui devra y accéder et comment ?

Si la plupart des besoins de 80% des applications sont assez standards, et couverts par des solutions répandues, ces questions peuvent être intéressantes dans certains cas. Et puis, on applique tout le temps la méthode, pour bien se rendre compte des limites et des points d'améliorations, voir pour changer d'approche : partager inutilement des données augmente les risques, par exemple. Dans le cas d’une source de données de type non structurée (fichier ou objet), qui ne nécessite pas de Middleware particulier, on pourra simplement le faire apparaître directement avec son type de protocole de partage (SMB, NFS, CIFS, S3, …).

Middlewares

La couche applicative est l’endroit où mettre en avant tous les logiciels permettant d’instancier concrètement ses flux, ses données et ses traitements. Concrètement:

• Logiciels d'échange comme RabbitMQ, sftpd, etc
• BDD
• Serveurs d'application (Web, Tomcat, etc)
• Services de sécurité réseau (WAF, FW, LB, proxy, reverse, VPN)
• Services d'authent ou de SSO

L'idée est d'être exhaustive sur les briques utilisées. La version d'un middleware est un élément à capturer impérativement. Souvent, les développements et surtout les progiciels sont dépendants de telle ou telle version, ce qui rend les évolutions potentiellement complexes. En identifiant dès le départ ces dépendances, on permet de mettre en avant la dette technique (c’est le coût qu’on est sûr de devoir financer dès lors qu’on a implémenté un composant, ne serait-ce que pour le retirer). Les évolutions de middlewares sont l'occasion de revenir sur l'analyse réalisée. On peut aussi mettre en avant certains mécanismes offerts par des middlewares, comme de la réplication de données, partage de session, clustering, chiffrement, etc.

Couche infrastructure

Globalement, la couche infrastructure traite de l’ensemble des mécanismes sous-jacents qui proposent des ressources et garantissent la performance, la disponibilité et la protection des données. On parle ici de serveurs, de réseau, de stockage, de virtualisation, de sauvegarde, d’archivage, de cloud bien sûr.

On distingue les infras mutualisées des infras dédiées. On va surtout se concentrer sur les infras mutualisées, les plus courantes. C’est la responsabilité de l’architecte d’avoir la curiosité de comprendre comment les infrastructures fonctionnent, et quelles sont les contraintes associées à chaque usage. La compréhension fine d’un service comme AWS S3 ou les Azure VM est indispensable à leur utilisation pertinente et raisonnée.

Ici chaque choix de composant devra se faire en prenant en compte l'exploit, ici aussi. Soyez gentils avec l'exploit :) Choisir de beaux trucs que personne ne maîtrise est toujours la recette d'un désastre à long terme.

Le calcul

Niveau le plus proche de l'applicatif, la partie calcul (serveur, conteneur, VM, etc) est décrite par trois éléments:

• Le dimensionnement : Niveau de perfs requis ? Nb de cpu ? Fréquence en GHz ? Taille mémoire ?
• L'emplacement : Quel datacenter ? Quel fournisseur cloud ?
• Identifiant : permet de faire le lien avec la couche applicative.

On peut aussi mettre en avant des éléments de clustering pour toujours se demander de quelle façon cela répond aux contraintes de service. Dans le cas de l'auto-scaling, on précisera les bornes d'elasticité et les critères de montée en charge.

Le réseau

• Comment les composants sont connectés ?
• Comment ils communiquent ?
• Quel débit ?
• Type de lien ?
• Redondance ?

Stockage

• Méthodes d'accès ? (SAN, NAS, Fibre Channel, Direct Attachment, Local... ?)
• Forme de stockage (bloc, fichier, objet ?)
• Type de disques, matériel ?
• Perfs ?
• Localisation du stockage (géographiquement) ? Important pour un PRA par ex.

On va aussi pouvoir détailler des fonctionnalités particulières : virtualisation, cluster actif/actif, chiffrement (c’est par exemple une fonctionnalité des Azure Storage Account), réplication synchrone et asynchrone, stockage Objet, etc. La couche infrastructure est aussi l’occasion d’analyser et de détailler les différentes machines physiques ou virtuelles dédiées à des usages spécifiques (appliances), comme par exemple un système d’archivage (support physique à écriture unique (WORM)) ou des fermes de calcul utilisant des GPU dédiés.

Couche Opérationnelle

Souvent le parent pauvre de l'architecture et de l'analyse, la partie opérations est essentielle. On doit pouvoir savoir comment le système va être supervisé, mesuré, sauvegardé, ordonnancé car cela influera sur sa résilience et son agilité.

Supervision

On va identifier des points de supervision, soit des éléments à surveiller sur lesquels on déclenche des alertes (des sondes, quoi). On suit la dispo et les perfs du services, je connais bien ça...

La finalité de la supervision est double : résoudre le plus rapidement les incidents, en ayant déjà identifié ses causes potentielles et si possible, les éviter. Côté architecture, on va donc s’assurer que les principaux aspects infrastructure (perte de réseau par exemple), applicatif (réponse d’un service web) et même fonctionnel (présence d’utilisateurs) sont couverts.

On va aussi décrire à quels systèmes de supervision ont est raccordés : les alertes ne seront pas traitées pareil selon qu'elles sont techniques ou fonctionnelles. Pour chaque point de supervision, on définit les seuils auxquels les alarmes doivent se déclencher, les actions à entreprendre et qui devra les faire.

Métrologie

Service complémentaire à la supervision, la métrologie permet de suivre et d’analyser un système à travers la collecte et l’exploitation des métriques.

L'architecte doit aider à identifier quelles sont les caractéristiques de ces métriques. Leur nature, la fq de collecte, la durée de rétention. Le mieux est de partir de quelques métriques que l'on est sûre d'utiliser et d'étendre au besoin. La métrologie sert aussi à mesurer des SLAs, par ex. en collectant des durées d'indispo.

Backup

La backup a pour but de garantir une PDMA. C’est à l’architecte de s’assurer comment la sauvegarde sera réalisée (LAN-Free, agent, à chaud, à froid, mécanisme middleware type archivage de logs…) et surtout si elle permet de respecter la politique de sauvegarde associée, et surtout de garantir les délais de restauration ! Cette politique de sauvegarde décrit la fréquence et la rétention des sauvegardes réalisées. Plus la fréquence est élevée, plus la rétention est courte en général.

Il ne faut pas penser que la réplication de données a valeur de sauvegarde. Une corruption de données ou un drop de base, par exemple, et notre réplication ne sert plus à rien !

La sauvegarde n’est pas importante, seule la capacité à restaurer l’est. Derrière cette tautologie se cache un aspect fondamental : seuls des tests de restauration réguliers peuvent réellement garantir que vos données sont bel et bien protégées.

Ordonnancement

Aspect majeur des applications très complexes et entremêlées, l’ordonnancement est la gestion de l'exécution de traitements successifs, en intégrant des possibilités de reprise et d’embranchement selon les résultats de chacun des traitements.

Il faut se poser la question de la dépendance du système à un mécanisme d'ordonnancement. Cela peut-être aussi simple qu'une crontab, ou aussi complexe qu'une application dédiée. Ce lien peut impacter la capacité à tenir des engagements, même si les chaînes d'ordonnancement peuvent parfois s'exécuter de façon autonome ou en mode dégradé. La compréhension des interdépendances fait partie du travail de l’architecte, tout comme le fait de s’assurer que les cas « classiques » bloquants sont pris en compte. Par exemple, valider avec le métier s’il est possible ou non d’ouvrir le service le matin si les sauvegardes nocturnes ne se sont pas exécutées correctement : ici, on prend une décisioni technique à partir de la compréhension des enjeux métier.

Déploiement, patches, et autres évolutions

L'analyse opérationnelle est aussi le moment de voir les contraintes posées par l'exploit : mécanismes de déploiement CI/CD, gestion des majs, rechargement des bases de données, gestion des logs, du NTP... L'idée est de creuser un peu pour se demander quels services opérationnels auront un impact sur notre système.

Document d'Architecture Technique

Le document d’architecture technique—DAT dans la suite de cours, ou TAD en anglais—est la pierre angulaire du travail de l’architecte. C’est à cet endroit que nous allons pouvoir capitaliser tout le travail de conception et documenter les hypothèses majeures retenues.

Avant de se lancer dans un DAT, il faut se poser la question de l'intention:

• À qui le document est-il destiné ?
• Quel message porte-t'il - Mettre en avant les contraintes d’exploitation ? Les engagements de service vis à vis du métier ? Les flux et les problématiques de filtrage ?

De nos jours, on a rarement besoin de documents fleuves. On s'appuie sur les experts de chaque partie pour connaître et appliquer les bonnes pratiques et apporter de la valeur ajoutée (sic). On préfèrera donc un document dit "tactique", qui met en avant les points d'attention, les décisions d'architecture, et qui représente les 4 couches décrites ci-avant.

Le DAT porte 4 objectifs :

• Porter la vision de l'architecture cible : avec les schémas des 4 couches
• Documenter les engagements divers : DIMA, PDMA, etc
• Présenter comment l'architecture cible y répond
• Décrire le travail à réaliser de façon macro, servant de ref pour la cheffe de projet
• Servir de support de communication afin de présenter efficacement le projet au management, aux archis, et aux équipes de prod

On peut éventuellement y ajouter des éléments de coûts, calendrier, contrat, etc... Le but étant de privilégier la clarté, il nous faut faire du tri dans les éléments que l'on va y représenter.

Avant de continuer, une précision importante : même si on parle d’un document d’architecture technique, sa forme doit être adaptée à son contexte d’utilisation : dans un cadre où le document doit être rédigé par de nombreux contributeurs, on préférera un wiki. Dans un contexte réglementaire, où le DAT fera office de référence contractuelle, un format type Word avec gestion de commentaires et marques de révision sera plus adapté. Dans un mode plus léger, où c’est l’aspect partage et présentation qui doit être mis en avant, un format type Powerpoint pourra être privilégié.

Application de la méthode de conception d'architecture

Nous allons voir l'application de la méthode pour produire un document d'architecture. L'architecture systèmes est un travail d'équipe : on ne peut pas tout faire seule. Nous allons suivre un plan type avec un exemple filé.

Contexte : les besoins fonctionnels

Partie la plus importante du DAT, elle correspond en gros à l'analyse fonctionnelle et répond aux questions suivantes :

• Que fait le système ?
• Quel a été l'historique du projet ?
• Quelles sont les attentes principales ?
• Qui sont les principaux acteurs ?
• Quelles directions sponsorisent le projet ?
• Quelles contraintes métier auront un impact sur l'architecture ?

Ici, il faut se concentrer sur les contraintes ayahnt trait à l'objet de l'application ou du système. Par exemple, “la page d'accueil doit se charger en 2 secondes” n’est pas un besoin fonctionnel (on ne peut pas construire une application dont la fonction soit “se charger en 2 secondes”) mais bien un besoin non-fonctionnel que décrit juste après. Un exemple de besoin fonctionnel serait : l'application Alice doit permettre aux clients de commander directement nos produits sur le web plutôt que de passer en magasin.

Besoins non fonctionnels

Il s'agit des contraintes techniques : performances, dispos, langages ou infras particulières, etc. L'exhaustivité et le partage de ces besoins non fonctionnels donne de la valeur à l'archi. Ces éléments doivent être présentés et discutés avec les parties prenantes.

Représentation fonctionnelle

Il s'agit ici de faire un schéma fonctionnel de notre système, comme décrit plus tôt. On va se demander : Quel message je veux faire passer ? Mettre l'accent sur les flux ? Les stocks ? Les blocs de traitement ? Classiquement, on va suivre le parcours de l'utilisateur dans le système.

Environnements et dimensionnements associés

Une fois l'analyse fonctionnelle faite, on va décliner chacune des archis applicatives et infras en fonction des environnements, soit les briques, ayant un usage dédié durant le cycle projet (test, formation, intégration, dev, prod...). On va donc ici lister ces briques avec quelques caractéristiques : nom et localisation, liste des services utilisés (cloud, serveur, bdd...), zones réseau, espaces de stockage (taille / nature), CPUs, etc : il faut avant tout se demander quelles données seront utiles à consigner.

Représentation applicative

Pareil, on va ici aussi schématiser les informations obtenues lors des entretiens. On peut en fonction de la complexité avoir plusieurs schémas applicatifs (par environnement, par zone réseau, par bloc fonctionnel...). Il faut aussi penser à garder un lien avec la couche fonctionnelle pour comprendre comment s'instancient les différentes fonctions, les flux et les gisements de données stocks.

On va encore une fois de suivre le parcours utilisateur, mais cette fois en faisant apparaître chacune des briques applicatives : serveur web, base de données, reverse proxy, firewall, partage de fichiers, ainsi que les logiciels ou progiciels utilisés. Il faut ici faire apparaître les flux techniques, avec leur port, leur protocole et bien respecter le sens d’initialisation du flux comme évoqué dans la deuxième partie.

La localisation de chacun des éléments est primordiale sur ce type de schéma (côté utilisateur, côté cloud, côté virtu, etc). Il faut aussi penser à faire apparaître le nom des infras sous-jacentes (noms des serveurs) pour faire le lien avec les schémas d'infra.

Matrice de flux

Extraite de l'analyse applicative. Liste des sources, destinations, protocoles et zones réseau pour chacun des flux applicatifs. On fait en général apparaître ici les échanges nécéssitant une approbation ou une ouverture de firewall, il faut faire apparaître les points d'attention : flux volumineux ou sensibles (latence...).

Représentation infra

Dans la lignée de nos schémas précédents, on va visualiser d'un coup d'oeil les ressources utilisées. On recommande d'afficher les configurations matérielles (OS, CPU, RAM, stockage) et les caractéristiques de dispo et résilience (réplication, clustering...). On doit faire le lien avec la partie applicative, à travers des identifiants communs (nom du serveur, rappel de sa fonction). Inutile de se perdre en parlant des services communs comme le réseau ou le stockage : autant renvoyer vers les DATs de ces éléments. On va seulement parler des détails particuliers comme un double attachement réseau, par exemple.

Représentation opérationnelle

On va montrer comment le système utilise les services d'exploitation. Comme pour l'infra, la plupart sont mutualisés. On va mettre en avant comment ils sont utilisés pour répondre aux contraintes. Par exemple, on mettra en avant une sauvegarde externalisée pour répondre aux besoins de reprise d'activité.

Offres de services d'opération

Il peut être pertinent de préciser à quelles offres de service notre système souscrit:

• Politique de backup
• Points de supervision et de métrologie
• Paramètres de déploiement continu : slots, fenêtres de déploiements, autorisation de certains utilisateurs...).

Décisions d'architecture

À partir de nos 4 analyses, on a fait des choix. Chaque décision doit être explicitée et capturée afin d'être examinée dans son contexte à l'avenir. On pourra ainsi remettre en cause nos choix et évoluer. Proposition de structure :

• Intitulé de la décisoin
• Contexte (pourquoi on prend cette décision)
• Alternatives considérées
• Justification pour expliquer la décision et le choix

Plan projet

On va pouvoir faire un plan projet, étant bien placé quant à la mise en oeuvre du projet en question. On va lister les tâches et les personnes, en utilisant la méthode RACI.

Calendrier de réalisation

À partir du plan projet, on peut faire un bon vieux GANTT !

Risques

On peut faire un peu d'analyse de risques à travers les étapes d'analyse, comme par ex. une sensibilité des performances en fonction du nombre d'utilisateurs. On doit pour chaque risque identifier l'impact et la probabilité, ainsi qu'un éventuel moyen de mitigation.

RACI opérations

Comme pour le projet, on doit faire une matrice RACI des opérations, pour savoir qui va exploiter les différents composants, applis et infras. Selon les contextes, on mettra l’accent sur l’organisation qui traitera, la distinction entre ressources internes et externes ou encore les périmètres infogérés.

Coûts

Comme le calendrier, les coûts sont essentiels pour faire émerger un système. Ici, on doit comprendre l'aspect technique des offres de service, des unités d'oeuvre ou des devis. On va s'intéresser à ce que coûtera la mep et le récurrent.

Revue par les pairs

Le DAT permet de structurer une vision, une réflexion, et d'expliciter des choix. Il doit être un outil de communication et d'échanges. La revue par les pairs est essentielle pour ne pas se perdre dans l'analyse. Pour couvrir tous les angles, il est nécessaire que tout travail soit revu et challengé. On a trois grands types de revues :

• Les comités d'architecture techniques et leurs variantes
• La revue en groupes d'architectes
• Les binômes.

Comité

Le comité d’architecture technique (CAT par la suite) a pour but principal de valider les systèmes ou applications en cours de conception. Le principe est de présenter son dossier à un groupe de représentants de la DSI : archis, séc, exploit, directeur technique, etc. C’est avant tout l’exhaustivité de l’analyse qui est regardée, en général au détriment de sa profondeur. Pour ce genre d’exercice, une communication optimale est nécessaire, que ce soit à l’oral ou à l’écrit.

Le but est d'avoir une appétence technique, tout en ayant des facilité à expliquer des concepts complexes. Il faut s'attendre à être questionnées sur des angles non identifiés au préalable, et on peut se retrouver à ajourner si notre design est remis en question. Autant perdre du temps au début que de tout reconstruire un an après.

Revue en groupe d'architectes

On expose moins les jeunes architectes et on prépare les dossiers de façon collégiale. On va surtout chercher la somme des expériences communes pour identifier les points faibles et les compléter au mieux. On assure aussi une qualité commune à une équipe de niveaux variés.

Elle permet le partage et le transfert de compétences sans sanctionner les imperfections, mais en les accompagnant.

Revue en binôme

Utile quand l'organisation de ne se prête pas à des comités. Le mieux est alors d'identifier un collègue qui sera le binôme et à qui présenter les travaux. En dev, on appelle ça la méthode du canard en plastique : on explique sa démarche à un canard en plastique (ou un collègue, ça évite de passer pour une débile). S'exprimer à voix haute permet de prendre du recul et d'améliorer sa qualité de réflexion. Les meilleurs canards sont ceux qui remettent les choix en question pour les optimiser.