Conseil en architecture cloud

Qu’est-ce que l’architecture cloud ?

L’architecture cloud définit où s’exécute chaque charge de travail, comment le trafic l’atteint, qui peut y accéder, comment ses données sont stockées et protégées, et ce qui se passe quand un composant, une zone ou une région entière tombe. C’est l’ensemble des décisions dont hérite le reste de la plateforme, et celles qui coûtent le plus cher à modifier une fois que le trafic de production en dépend.

L’objectif n’est pas un schéma parfait. C’est une plateforme qui répond aux exigences métier de disponibilité, de latence, de sécurité et de coûts, et que vos ingénieurs peuvent exploiter et faire évoluer sans appeler son concepteur d’origine. Une bonne architecture se juge au peu de surprises qu’elle réserve sur toute sa durée de vie, pas à l’effet qu’elle produit le jour de sa présentation.

Le travail prend deux formes. Une revue examine un environnement déjà en production et indique ce qu’il faut conserver, ce qu’il faut corriger et dans quel ordre. Une conception part des exigences, pour un nouveau produit, une configuration hybride ou une seconde région, et produit une cible constructible. Les deux font partie de notre expertise en conseil cloud, et une conception prépare souvent une migration cloud planifiée.

Les signes qu’une revue d’architecture cloud s’impose

Les problèmes d’architecture s’annoncent rarement. Ils se manifestent par des incidents qui s’éternisent, des projets bloqués et des audits qui traînent pendant des mois. Voici les signaux que nous guettons lors d’un premier échange, car chacun pointe vers une partie différente de l’architecture.

• La panne d’une zone ferait tomber la production

  Instances, bases de données ou passerelles se trouvent dans une seule zone de disponibilité, et personne n’a testé ce qui se passe si cette zone disparaît.

• Des objectifs de reprise sur le papier, jamais testés

  Les valeurs de RTO et de RPO figurent dans les contrats, mais aucune restauration ni aucun basculement n’a été mené pour les vérifier depuis un an.

• Chaque projet relance le débat sur le réseau et les identités

  Sans landing zone ni conventions partagées, chaque équipe conçoit comptes, sous-réseaux et rôles de zéro, et différemment à chaque fois.

• Les limites de montée en charge se découvrent en production

  Quotas, connexions à la base de données ou composant stateful atteignent leur plafond pendant un pic, parce que personne n’a écrit les seuils.

• L’architecture n’existe que dans la tête d’une seule personne

  Quand l’ingénieur qui l’a construite est absent, les incidents durent plus longtemps et les changements attendent. L’intégration des nouveaux repose sur la tradition orale.

Si au moins deux de ces situations vous parlent, une revue coûte généralement moins cher que le prochain incident grave. Elle vous donne aussi une référence écrite avant tout changement d’envergure, comme l’ouverture d’une nouvelle région, le passage d’un audit ou l’intégration des systèmes d’une société rachetée.

Ce que couvre notre mission d’architecture

Revue ou conception, les livrables relèvent du même type de document : des décisions avec leurs justifications, des schémas conformes à ce qui est déployé et des procédures exécutées au moins une fois. Nous commençons par la cartographie de vos applications et de leurs dépendances, car aucune architecture ne vaut mieux que l’inventaire dont elle part.

• Exigences et contraintes, exprimées en chiffres

  Disponibilité, latence, objectifs de reprise, résidence des données et budget, validés avec le métier avant toute comparaison d’options.

• Registres de décisions d’architecture

  Chaque choix important documenté avec les options étudiées, les compromis acceptés et les conditions qui nous amèneraient à le revoir.

• Landing zone et socle de sécurité

  Structure des comptes ou abonnements, topologie réseau, identités et accès, chiffrement et garde-fous, spécifiés pour pouvoir être écrits en infrastructure as code.

• Conception de la résilience et de la reprise après sinistre

  Modes de défaillance par composant, procédures de sauvegarde et de basculement, et un test de reprise mené par rapport aux objectifs fixés.

• Seuils de montée en charge et plan de capacité

  Les limites connues de chaque composant, les métriques qui alertent avant qu’elles ne soient atteintes, et l’étape suivante quand elles le sont.

Tout est rédigé pour que votre équipe, ou un autre partenaire, puisse l’implémenter. Si vous souhaitez que nous construisions aussi, les mêmes consultants traduisent l’architecture en code, ce qui supprime la perte habituelle entre ce que l’architecte avait en tête et ce qui est réellement déployé.

Notre méthode de conception en quatre phases

Chaque phase produit un document dont dépend la suivante, et chacune se termine par une revue où vous pouvez changer de cap. Rien n’est conçu avant la validation des exigences, et rien n’est déclaré terminé avant d’avoir été testé.

C’est à l’étape de validation que beaucoup d’architectures échouent sans bruit. Nous menons au moins une restauration et un basculement par rapport aux objectifs de reprise fixés, ainsi qu’un test de charge par rapport aux seuils de montée en charge, avant de déclarer l’architecture terminée. Les écarts constatés retournent dans les registres de décisions, pas dans une note de bas de page. Pour décider quoi surveiller une fois la plateforme en production, notre plan de monitoring et d’alertes avec des seuils calibrés constitue un bon point de départ.

Une région, plusieurs régions ou hybride ?

La topologie est la décision qui pèse le plus sur les coûts et la complexité. Davantage de régions et d’environnements apportent de la résilience, mais chacun doit être déployé, sécurisé, testé et payé. Nous choisissons la topologie la plus simple qui respecte les objectifs de reprise écrits, et nous indiquons ce qu’il faudrait pour passer au niveau supérieur.

Le multi-cloud est l’option que nous recommandons le moins souvent, car il double les compétences et l’outillage pour un bénéfice dont peu de charges de travail ont besoin. Quand c’est la bonne réponse, la justification figure dans un registre de décisions. Avant de vous engager sur une topologie, une analyse des risques cloud, des blocages et des dépendances critiques montre quelles contraintes sont réelles et lesquelles relèvent de l’hypothèse.

Les risques d’architecture que nous éliminons dès la conception

Certains risques d’architecture sont visibles dès le premier jour, d’autres n’apparaissent qu’après un an de croissance. Nous traitons chacun des points suivants comme une exigence de conception avec un responsable, pas comme une chose à corriger après la première panne.

• Des points de défaillance uniques dans les services partagés

  Le DNS, le fournisseur d’identité, une base de données partagée ou un runner de build peuvent tout faire tomber. Nous les recensons par charge de travail.

• Un rayon d’impact trop large

  Un seul compte, un seul réseau ou un seul jeu d’identifiants pour tout signifie qu’une erreur atteint tout. Des frontières limitent les dégâts.

• Une reprise qui dépend du composant défaillant

  Des sauvegardes conservées dans le même compte, ou des runbooks hébergés sur la plateforme qu’ils doivent restaurer, échouent précisément quand on en a besoin.

• Des architectures qui ignorent le coût d’exploitation

  Une architecture qui répond à toutes les exigences mais double la facture n’est pas terminée. Le coût est estimé pour chaque option, avant la décision.

• Une dérive entre l’architecture et ce qui est déployé

  Les modifications manuelles s’accumulent jusqu’à ce que les schémas mentent. L’infrastructure as code et des revues périodiques maintiennent les deux alignés.

Quand une revue détecte ces problèmes dans un environnement existant, nous ordonnons les corrections selon le risque éliminé par semaine d’effort, afin de combler d’abord les failles les plus dangereuses. Notre guide sur la remédiation par étapes de la dette technique de l’infrastructure cloud décrit comment ce plan est construit et suivi.

Tarifs de l’architecture cloud

Chaque mission commence par un diagnostic et se conclut par un devis forfaitaire. Les durées sont indicatives, pas garanties.

Ce qui fait varier le prix : le nombre de charges de travail et d’environnements, les objectifs de reprise, les contraintes de conformité et de résidence des données, et le fait que nous construisions aussi l’architecture.

Le devis couvre uniquement des consultants seniors, un périmètre défini et les livrables de chaque phase : registres de décisions, schémas, spécification de la landing zone et résultats des tests de reprise. Les coûts du fournisseur cloud, y compris les environnements temporaires créés pour la validation, sont facturés par le fournisseur et estimés avant le début des travaux.

FAQ architecture cloud