L’un des risques majeurs des trajectoires de modernisation vers le Cloud Native est paradoxalement bien connu : vouloir mieux faire, mais reproduire des schémas anciens dans un environnement nouveau. La sécurité by design est souvent invoquée comme un principe fondateur de ces architectures modernes. Pourtant, dans la pratique, elle peut facilement se transformer en une nouvelle ligne de fracture entre les équipes, si elle n’est pas pensée avec discernement.

Dans un contexte comme celui d’un réseau de soins et d’un opérateur de tiers payant tel que Carte Blanche Partenaires, cette question est particulièrement sensible. Les exigences métier sont fortes, les attentes en matière de disponibilité élevées, et la tolérance à l’erreur limitée. La sécurité by design ne peut donc pas être vécue comme une contrainte supplémentaire imposée aux équipes, mais comme une condition de fiabilité du système d’information.

Le Cloud Native modifie profondément la manière dont la sécurité s’intègre aux projets. Dans des architectures plus traditionnelles, la sécurité intervenait souvent en aval, sous forme de contrôles ou de validations ponctuelles. Dans un environnement Cloud Native, cette approche montre rapidement ses limites. Les cycles de déploiement sont plus courts, les changements plus fréquents, et les interactions entre composants plus nombreuses. Attendre la fin du processus pour introduire la sécurité revient à courir après un système déjà en mouvement.

Pour autant, intégrer la sécurité dès la conception ne signifie pas tout verrouiller. L’un des écueils les plus fréquents consiste à transposer des exigences conçues pour des environnements statiques dans des architectures dynamiques. Cette transposition peut générer de la friction, ralentir inutilement les équipes et, in fine, créer un rejet de la sécurité. La sécurité by design perd alors son sens et devient un facteur de contournement plutôt que de protection.

L’enjeu réel se situe dans la lisibilité des règles. Dans un environnement Cloud Native, les équipes ont besoin de cadres clairs, stables et compréhensibles. Des principes plutôt que des prescriptions excessivement détaillées. Des règles qui expliquent le pourquoi, pas uniquement le quoi. Cette approche permet d’intégrer la sécurité dans les pratiques quotidiennes sans alourdir les processus.

Du point de vue du DSI/RSSI, la difficulté consiste à maintenir cet équilibre dans le temps. Les architectures évoluent, les services se multiplient, les dépendances externes augmentent. La sécurité by design ne peut pas être figée. Elle doit évoluer avec le système d’information, tout en conservant une cohérence globale. C’est ici que la gouvernance joue un rôle central, en définissant des trajectoires plutôt que des états figés.

Un autre point clé concerne la responsabilité. Dans des environnements Cloud Native, de nombreuses décisions sont prises très en amont, parfois directement par les équipes de développement ou d’exploitation. Cette autonomie est une force, mais elle suppose un cadre clair sur ce qui relève de la décision locale et ce qui engage l’organisation dans son ensemble. La sécurité by design n’est pas l’affaire d’une seule équipe. Elle est un engagement collectif, porté par des règles partagées et des arbitrages explicites.

Cette articulation est d’autant plus délicate lorsque les exigences métier sont fortes. La pression pour livrer, pour adapter rapidement les services, peut entrer en tension avec des impératifs de sécurité ou de conformité. Le rôle du DSI/RSSI n’est pas d’arbitrer en permanence au cas par cas, mais de créer un cadre qui permette aux équipes de prendre de bonnes décisions par elles-mêmes. Lorsque la sécurité est intégrée dès la conception, elle cesse d’être un point de blocage et devient un facteur de fluidité.

Dans la pratique, cela suppose un dialogue constant entre les équipes IT, sécurité et métiers. Un dialogue qui ne se limite pas aux incidents ou aux audits, mais qui s’inscrit dans la durée. La sécurité by design est moins une question d’outils que de culture. Elle repose sur une compréhension partagée des enjeux et sur une confiance construite progressivement.

Le Cloud Native offre une opportunité rare de repenser cette articulation. Il permet d’automatiser certains contrôles, de standardiser des pratiques et de renforcer la résilience globale du système d’information. Mais ces bénéfices ne se concrétisent que si la sécurité est intégrée de manière intelligente, sans recréer les silos que l’on cherche précisément à dépasser.

Trouver cet équilibre est exigeant. Il nécessite de renoncer à certaines certitudes, d’accepter une part d’expérimentation et de faire évoluer les pratiques au fil du temps. Mais c’est aussi ce qui permet de construire un système d’information moderne, robuste et aligné avec les attentes des métiers.

Dans le prochain article, je proposerai une réflexion complémentaire sur un sujet souvent sous-estimé dans les trajectoires Cloud Native : la résilience opérationnelle et la manière dont elle doit être pensée conjointement par le DSI et le RSSI, au-delà des seuls aspects techniques.