Mini DAT Cloud ☁️

Au non pas un DAT 🥹

Généralement, la réalisation de livraison écrite est souvent la bête noire de l'informaticien.
Et pourtant, je vais essayer de vous réconcilier avec la réalisation d'un document d'architecture technique MEME si ce n'est pas imposé par votre service informatique.

J'aimerais vous faire part de ma vision très orientée infrastructure cloud, elle ne collera pas à 100% avec votre spécialité on-prem ou même logiciel mais je suis sûr que tout n'est pas à jeter... Enfin, peut-être...

Premièrement, ce N'EST PAS UNE PUNITION. L'objectif est de vous poser les bonnes questions avant de vous lancer tête baissée dans la mise en PROD de votre infrastructure. Vous me remercierez quand vous verrez vos collègues faire un rollback à 1 semaine de la MEP mais pas vous.

Imaginez, vous récupérez un vieux sujet poussiéreux totalement WTF. Et là, vous trouvez le saint graal, le DAT.
Si celui-ci est bien réalisé, vous allez comprendre pourquoi une solution a été designée comme ça. Il y a beaucoup d'esprit malade dans ce monde (dont je fais très certainement partie) mais parfois ils ont leur raison et le DAT nous aide à y voir un peu plus clair.
Alors, vous aussi contribuez à l'équilibre mental de la prochaine personne qui récupérera votre travail 😉.

N'oubliez pas qui est la cible de ce document, votre direction, une autre équipe, des architectes de solution... etc.
Ce sont eux qui vont valider votre projet. L'objectif est de rassurer et montrer que vous maîtrisez votre sujet. Il faudra donc adapter votre discours.

Une fois validé, il vous servira de bouclier en cas de problème. Vous serez factuel, "en fonction de cette exigence et de cette contrainte voici les solutions techniques que je vous propose". Si celles-ci viennent à évoluer ou ne vous ont tout simplement pas été communiquées, vous ne pouvez pas être tenu responsable de quelque chose que vous ignorez. Boomerang boomerang ! Tout ce que tu dis ça revient vers toi. 🏄🏻‍♂️
Bon, il vous faut quand même jouer le jeu. Il vous faut faire ce travail d'investigation, vous n'allez pas vous en tirer comme ça.

Comme pour chaque sujet, il n'y a pas une seule façon de l'aborder, ceci reste ma vision et les grandes lignes de mes pensées basées sur mon expérience.
Il existe de nombreux livres, de nombreuses autres personnes qui parlent de ce sujet, à vous de prendre le meilleur de chacun.
Je vais vous expliquer (pour moi) de quoi doit être composé au minimum un DAT en 2025. Il peut être plus ou moins détaillé en fonction des exigences de la solution.

Personnellement, j'aime les choses simples et faciles à lire. Je privilégie un document principal pas très long et non ennuyeux, quitte à détailler dans une annexe ou un document dédié.
Fini les DAT de 150 pages que personne ne lit et qui mettent 6 mois à être écrits (et qui coûtent bien trop cher).
N'oubliez dans quel monde nous vivons. Nous demandons à des IA de nous écrire des romans, pour finir par demander à d'autres IA de résumer ce même roman. Autant écrire de suite quelque chose qu'un humain va pouvoir lire sans cramer la moitié de l'amazoni.

Cet article est décomposé en plusieurs chapitres avec des sujets macro, vous ne trouverez pas ici un guide complet. À vous de faire vos recherches et de l'adapter en fonction de votre contexte.

Bon allez, j'ai déjà trop parlé, les infos sont juste ici. 👇

Chapitres

Exigences / Contraintes

Vous pouvez avoir vos propres exigences et contraintes, mais en entreprise vous ne créez pas une infrastructure pour vous.
Elle est souvent commandée pour le business, ce sont eux qui doivent vous donner la plus part de ces informations. Pensez au service final que vous devez rendre.
N'oubliez pas au passage les différentes équipes comme la sécurité, le réseau, la gestion d'identité...etc. Elles peuvent avoir des contraintes plus ou moins complexes. Sans ça, l'approbation et l'intégration seront tout simplement impossibles.

Cela peut être des fixes / améliorations / nouveaux besoins métier / budget financier alloué pour l'hébergement de votre solution / disponibilité / scalabilité / sécurité au niveau du SI / contrainte de gouvernance (landing zone) ou organisationnelle.

Représentez tout ça dans un tableau avec des ID et faites-y appel dans le reste du document pour appuyer vos choix.

⚠️ N'oubliez pas, c'est le business/projet qui doit donner ces exigences ⚠️

PS : Il se peut qu'une exigence soit incompatible avec une contrainte donnée par une autre équipe. Si ce n'est pas surmontable d'aucune façon et que sans ça le projet ne peut pas fonctionner, ne perdez pas du temps à réaliser le reste de l'étude. La probabilité d'aller à l'implémentation est faible, connectez-vous sur Candy Crush et passez un bon moment. (Cet article n'est pas sponsorisé)

Analyse de l'existant

Avant de savoir où l'on va, il faut savoir d'où l'on vient. Il est possible de commencer sur un projet totalement vierge mais dans la plupart des cas, il y a toujours un POC, un ancien environnement, de la dev dans un coin, ou même le fameux PC data center présent sous un bureau.
Vous l'avez compris, l'objectif est de récupérer tous les schémas, inventaire, ressources, volumétrie, nombre d'utilisateurs, le coût actuel, quelle équipe gère le projet, les utilisateurs concernés, que vous pouvez trouver.

Propositions

Faites plusieurs propositions.
Elles doivent être en lien avec les exigences/contraintes mais aussi avec les bonnes pratiques de la techno.
Si l'éditeur est sérieux, il vous donnera toutes les informations nécessaires pour implémenter le/les service(s) avec les bonnes pratiques.
C'est le moment de faire appel à vos ID du chapitre "Exigences / Contraintes" 😉

N'oubliez pas qu'un schéma vaut 1000 mots.

Les solutions les plus simples sont souvent les plus maintenables. Montrer que vous avez les capacités intellectuelles de construire une machine à gaz alors que vous n'en avez pas besoin est juste de l'égo, et ça fait perdre du temps à tout le monde !

Interconnexion externe

À moins que votre solution soit totalement isolée du reste du monde, vous aurez besoin de vous interconnecter.
Je vous conseille de faire également un schéma.
N'oubliez aucun élément qui communique avec votre future infrastructure.
Vous pourrez également vous servir de ces éléments pour éventuellement démontrer que votre solution répond au besoin mais qu'un élément extérieur représente un risque.

Mise en œuvre / migration / évolution

Ce chapitre est composé de deux grosses parties.

1. Le plan de mise en œuvre/migration. Concrètement, comment allez-vous mettre en place cette solution. La question préférée de vos supérieurs : "Combien". Combien de temps il faut, avec combien de personnes, et enfin combien cela va me coûter. Si jamais on ne vous pose pas cette question, je vous offrirai une menthe à l'eau volontiers 🍹. Nous sommes en 2025, alors s'il vous plaît, incluez dans votre plan l'utilisation de l'infrastructure as code.
2. Une fois que vous l'avez mise en place (félicitations), il vous faudra le faire évoluer, en gros le setting et l'upgrade. Une seule solution, une pipeline CI/CD. Hors de question de faire une modification manuellement et sans vérification.

Pour ces deux piliers, vous avez une multitude de techniques, à vous de choisir ce qui vous convient le mieux.

Quelques petits exemples :

• Blue green
• Canary
• Rolling-upgrade
• A/B testing
• Recreate deployment

Et pour le choix du pipeline, je pense que vous n'aurez pas trop de mal à trouver chaussure à votre pied.

MCO

MCO pour maintien en condition opérationnelle.
En fonction de l'infrastructure, il est probable que certains composants nécessitent d'être chouchoutés.
L'objectif est de déterminer quel composant nécessite une intervention.
Il est possible d'aller plus loin, en donnant la fréquence, le risque, l'obsolescence déjà annoncée.
Dans le cloud, beaucoup de ressources sont managées, mais n'oubliez pas que certaines d'entre elles ne le sont pas. Les mises à jour, hot fixes, montées de version sont possibles tout au long de la vie de votre infrastructure.
Hormis le fait que votre infrastructure ne fonctionnera tout simplement pas. Vous vous risquez à des failles de sécurité qui auront un effet tout aussi dévastateur sur votre réputation qu'une indisponibilité.

Supervision

Plusieurs éléments abordés dans cette partie.

• Logs applicatifs
• Logs infrastructure
• Health check sur les services et/ou test end to end
• CPU / RAM / Disque
• Consommation avec des budgets et des alertes
• CMDB

Nous devons savoir ce qu'il se passe. Référencez les composants critiques qui méritent une attention particulière. Dans tous les cas, rien n'est écrit dans le marbre. Vous allez faire évoluer la supervision en fonction de vos besoins.
Il est important de ne pas partir sans aucune visibilité. Sans ça, vous ne pourriez pas savoir si votre solution est fonctionnelle à 100% ou non. C'est quand même dommage d'avoir travaillé si dur pour échouer aussi rapidement.

Backup / PRA

Votre capacité à restaurer une partie ou en intégralité votre solution est primordiale.
Ne pensez pas que les problèmes n'arrivent qu'aux autres et que les backups sont secondaires.
Même les plus grandes sociétés tech ont eu leur nom dans les journaux.
La phrase "tester c'est douter" est très sympa devant la machine à café mais beaucoup moins à 3 heures du matin.

N'oubliez pas d'inclure des tests de restauration/déploiement. Ce n'est pas parce que votre Terraform a très bien fonctionné il y a 3 ans, qu'il sera aussi facile de le redéployer.

Concentrez-vous sur les composants state-full en priorité.

Pour des plans de reprise d'activité (PRA) évolués, il est tout à fait envisageable d'imaginer une solution capable d'adopter une stratégie multi-régionale voire même multicloud selon la criticité.
Pour aller plus loin, nous pouvons parler des RPO / RTO.
C'est un sujet complexe, cela peut faire l'objet d'un document dédié.

Bon maintenant que vous avez pris un bon petit coup de chaud, n'oubliez pas que certains projets ne sont pas critiques. Il est tout à fait entendable d'avoir un SLA très élevé si le business le permet.

Tout cela a un coût et il doit être étudié.

Analyse de risque / Sécurité

C'est un vaste sujet.
Première étape, posez-vous la question : Votre nouvelle solution représente-t-elle un risque pour le système informatique existant ?
Y aura-t-il des effets de bord ?
Si oui, comment allez-vous les gérer ?

L'analyse de risque doit également prendre en compte des limites potentielles au niveau de vos services, composants, connexions ou même providers. Que ce soit des soft ou des hard limits.

Vous devez apporter des réponses à vos risques.

Et enfin, il vous faut une stratégie de contrôle ou de pentest pour vous assurer que tout est en conformité.

FinOps

On va parler pognon ! Le prix de votre infrastructure va impacter directement sur les bénéfices de l'entreprise.
C'est comme ça. Ça coûtera toujours trop cher pour la direction et pour les actionnaires.

Il est important de récupérer le budget alloué pendant la phase de "Exigences / Contraintes" évoquée précédemment.

Pas de magie, vous allez devoir être en-dessous.
Présentez une budgétisation macroscopique avec une évolution dans le temps. Certains services transverses comme les logs et les backups peuvent coûter plus cher au fur et à mesure.
Le plus compliqué va être la budgétisation de la charge. Bonne chance... Je n'ai pas de solution miracle, cela sera du prévisionnel.
À vous de réaliser votre budget réel et de vous assurer que les objectifs financiers sont atteints.

Présentez donc un budget macroscopique ainsi que des solutions concrètes pour réduire les coûts.
Création automatique d'infrastructure de hors prod à la demande, scaling et sizing des ressources maîtrisées, shutdown de certains composants non critiques. Tout est bon à prendre.
Si possible, comparez avec la consommation existante.
Vous pouvez aussi aborder la facilité de refacturation en fonction du modèle économique adopté.

Pour appuyer l'importance du FinOps, sentez-vous libre d'évoquer que certaines entreprises ont dû mettre la clé sous la porte parce que leur coût d'infrastructure était trop élevé pour pouvoir se dégager du bénéfice.
Vous êtes tous dans la même équipe.

Au cours de mon expérience passée, j'ai pu voir des économies de plus de 30% seulement grâce à un peu de ménage et une bonne gouvernance. Ne vous inquiétez pas pour moi, je n'ai reçu 30% d'augmentation.
Mais peut-être que vous pourriez valoriser ce gain en l'utilisant pour de la R&D ou des chocolats pour Noël. 🤗

Recrutement / formation / structuration d'équipe

Cette partie est pour moi constamment oubliée ou minimisée.
Le changement n'est pas anodin. Vous allez trouver beaucoup de réfractaires à utiliser de nouvelles technologies ou méthodes.
R.I.P aux personnes qui n'ont pas voulu utiliser l'outil informatique il y a 30 ans et qui disaient qu'internet n'était qu'une mode... 🪦

Plus sérieusement, l'objectif, vous l'avez compris, est de n'oublier personne 😇. Si vous pensez by design à l'accompagnement au changement, vous éviterez énormément de friction.
N'oubliez pas que chaque personne en accord avec votre solution est un sponsor potentiel qui contribuera au bon déroulement de votre implémentation.

Les questions à vous poser :

• Les équipes doivent-elles être formées ?
• Faut-il embaucher de nouvelles personnes ?
• Doit-on restructurer les équipes ?
• Voir, doit-on faire une réduction d'effectifs car la nouvelle solution ne nécessite plus autant de personnes ?

Ne négligez pas ce chapitre, pensez aux autres, c'est aussi penser à vous !

Documentation

Pas de grande surprise, référencez ici tous les liens vers différents docs / blogs / REX / vidéos / blueprints utilisés pour réaliser ce document.

MAIS aussi, mettez en évidence comment vous allez référencer et documenter votre nouvelle super infra.
N'oubliez pas à quel point il est compliqué de reprendre un sujet sans aucune information.

Et si je suis tout seul, comment je fais ?!

Effectivement, j'ai orienté mon document plutôt pour des entreprises type TPE, PME, grand groupe 🥲.
Mais quand est-il de nos amis les solopreneurs ?
Et oui, je ne vous ai pas oubliés, futur vibs codeur ex-boulanger.
Votre route sera longue. Si j'ai un seul conseil à vous donner, utilisez ces nouveaux fabuleux outils comme porte d'entrée dans le joyeux monde de l'informatique.
Gardez en tête tout ce que vous avez pu lire ici, faites-vous un mini DAT pour ne pas oublier des étapes et surtout faites-vous accompagner par des professionnels qui ont de l'expérience le moment venu.
Les deux univers ne sont pas incompatibles 🫶, tout est encore une fois une question d'équilibre.
Tout le monde a de bonnes idées, mais la concrétisation est bien plus compliquée.

Conclusion

Rome ne s'est pas bâtie en un jour.
Écrire de jolies phrases dans un document n'est pas toujours simple, alors imaginez quand il s'agit de leur donner vie.
Implémenter tous les points de votre DAT est un objectif, avoir cette maturité d'infrastructure et la garder dans le temps n'est pas chose facile.
Vous allez devoir naviguer avec les cartes que vous avez en main et le DAT vous servira de guide☀️.