Architecte IT : patterns, contraintes de sécurité et dette structurelle
L'architecte d'un système d'information conçoit les structures qui porteront les applications et les données sur plusieurs années : découpage des composants, flux entre eux, choix d'hébergement, modèle de sécurité. Son travail se juge rarement au moment où il le produit et presque toujours trois ans plus tard, lorsqu'il s'agit de faire évoluer ce qui a été posé. Cette page rassemble les contenus publiés par la rédaction d'ITPro.fr à l'intention des architectes, dans le prolongement de nos hubs cloud et infrastructure et cybersécurité.
L'architecte arbitre entre des contraintes qui s'opposent
Performance, coût, sécurité, réversibilité, simplicité d'exploitation : ces cinq exigences ne sont jamais satisfaites simultanément. L'architecture consiste précisément à décider laquelle est sacrifiée, et à l'écrire. Les décisions non documentées produisent le symptôme le plus courant des systèmes anciens, celui où personne ne sait plus pourquoi un composant existe ni ce qui se casserait en le retirant. Tenir un registre des décisions d'architecture, avec le contexte et l'alternative écartée, coûte peu et transforme la capacité d'évolution d'un système.
Sécuriser sa téléphonie IP n’est plus une option. Avec la généralisation de la téléphonie cloud et des infrastructures VoIP, la voix circule désormais sur les mêmes réseaux que les données…
La sécurité est devenue une contrainte de conception, pas une couche
Ajouter la sécurité après coup produit des dispositifs contournés par les usages ou désactivés sous la pression des délais. Les modèles qui tiennent intègrent dès la conception la vérification de chaque accès, la segmentation des ressources et la limitation des droits permanents, principes développés dans notre rubrique Zero Trust. La conséquence pratique pour l'architecte est que l'identité devient un composant d'architecture de premier rang, au même titre que la base de données ou le réseau, sujet traité dans notre rubrique gestion des identités et des accès.
L'intégration de la détection se pense en amont
Un système conçu sans réflexion sur la journalisation produit des traces inexploitables : formats hétérogènes, horodatages non synchronisés, absence de corrélation possible entre les couches. L'équipe sécurité découvre le problème au moment de l'incident, lorsqu'il est trop tard pour y remédier. Décider en conception quels événements sont produits, dans quel format et avec quelle rétention est un travail d'architecture, pas une tâche d'exploitation. Les dispositifs de collecte et de corrélation sont détaillés dans nos rubriques EDR et XDR, SIEM et SOC.
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et…
Les patterns vieillissent inégalement
Certains choix traversent les années sans difficulté : la séparation des responsabilités, l'idempotence des traitements, l'interface explicite entre composants. D'autres se révèlent coûteux dès que l'échelle change : le découpage trop fin qui multiplie les appels réseau, l'orchestration généralisée sur un périmètre qui ne la justifiait pas, le couplage par la base de données partagée. Le critère qui départage n'est pas la mode mais la question de savoir ce qui devra être modifié le jour où une hypothèse initiale tombe. Ces arbitrages sont traités dans nos rubriques Kubernetes et conteneurs et cloud hybride et multicloud.
La dette d'architecture ne se voit pas dans le code
Un code propre peut reposer sur une structure qui interdit toute évolution. La dette d'architecture se manifeste autrement : par le nombre d'équipes à coordonner pour livrer une fonctionnalité, par l'impossibilité de tester un composant isolément, par la durée d'un environnement de recette. Ces signaux sont mesurables et devraient figurer dans le pilotage au même titre que les indicateurs de qualité de code, point développé dans notre rubrique CI/CD et DevSecOps.
Ce que vous trouverez sur ITPro.fr
Questions fréquentes
Quelle différence entre architecte SI, architecte solution et architecte sécurité ?
L'architecte SI conçoit la structure d'ensemble du système d'information et ses grands découpages. L'architecte solution intervient sur le périmètre d'une application ou d'un projet. L'architecte sécurité porte les exigences de protection dans ces deux travaux. Dans les organisations de taille intermédiaire, une même personne exerce fréquemment les trois rôles.
Qu'est-ce qu'un registre de décisions d'architecture ?
C'est un document qui consigne chaque décision structurante avec son contexte, les alternatives examinées et la raison du choix. Son intérêt se révèle des années plus tard, quand il s'agit de savoir si une contrainte justifie encore un composant. Son coût de tenue est faible au regard du temps perdu à reconstituer des décisions oubliées.
Comment intégrer la sécurité dès la conception ?
En traitant trois éléments comme des composants d'architecture et non comme des options : l'identité et le contrôle d'accès, la segmentation des ressources, et la production d'événements exploitables par la détection. Ces trois points sont très coûteux à ajouter après la mise en production et peu coûteux à prévoir en conception.
