Croître dans le cloud exige des limites claires.

Les comptes, les environnements et les droits d'administration doivent correspondre à l'organisation réelle. Une séparation par métiers n'est pas toujours identique à une séparation par applications ou par responsabilité d'exploitation. Nous examinons donc ensemble qui demande des ressources, qui les prend en charge et à qui les dépenses doivent être imputées. Les environnements existants sont également pris en compte. La vision cible décrit ensuite les frontières souhaitées et leurs raisons, afin que les modifications ultérieures ne soient pas décidées uniquement sur la base de noms apparus au hasard ou de responsabilités historiques.

Le développement, les tests et la production sont séparés les uns des autres dans la mesure nécessaire. On définit en outre comment les services communs sont utilisés et quelles exceptions peuvent être admises. La mise en œuvre ne doit pas empêcher toute particularité, mais permettre d'y répondre de manière vérifiable. Une procédure d'exception encadrée précise la décision et la responsabilité. L'architecture reste ainsi explicable, même lorsque certaines applications ont des exigences particulières ou qu'une charge de travail existante ne peut d'abord être intégrée que progressivement dans la structure commune.

Une politique documentée ne modifie encore aucune ressource. Pour les règles convenues, on vérifie donc lesquelles peuvent être mises en œuvre techniquement et lesquelles nécessitent encore une décision organisationnelle. Cela comprend les rôles, les accès réseau, la journalisation et l'étiquetage des coûts. La configuration doit permettre de reconnaître quelles règles s'appliquent de manière contraignante et où des validations sont requises. Dans le même temps, la procédure de modification est décrite, afin qu'une adaptation ultérieure n'ait pas à se faire en dehors de la base commune.

Une configuration versionnée permet de vérifier les modifications et de consigner de manière vérifiable l'état souhaité. Dans le périmètre convenu, elle sert de base à un processus de déploiement reproductible. Celui-ci est testé avec un environnement concret, y compris les vérifications et les accès nécessaires. Votre équipe reçoit la configuration ainsi que les procédures pour son utilisation. Une plateforme mise en place une fois devient ainsi une base sur laquelle d'autres projets peuvent s'appuyer, et dont la maintenance n'incombe pas uniquement aux personnes ayant participé au projet initial.

C'est une application réelle qui montre si la Landing Zone est praticable. Votre équipe doit recevoir les ressources prévues, accéder aux systèmes nécessaires et pouvoir réaliser son travail avec les droits qui lui sont attribués. Ce premier passage met en évidence les informations manquantes et les obstacles inutiles. Nous distinguons alors ensemble ce qui relève d'une exigence nécessaire et ce qui relève d'un processus à simplifier. Les observations sont intégrées à la configuration et à la documentation avant l'intégration d'autres équipes.

Le transfert comprend la responsabilité de la maintenance de la plateforme, l'intégration de nouveaux projets et la validation des modifications. Les points en suspens sont également documentés avec leurs conséquences. Une Landing Zone ne constitue pas une confirmation définitive de sécurité ou de conformité pour chaque application qui y sera exploitée ultérieurement. La configuration et l'utilisation de ces applications restent à examiner séparément. La base ainsi créée soutient ces tâches en fournissant des procédures communes et en rendant visible la responsabilité liée aux extensions et aux écarts.