Chez DoiT, j'accompagne au quotidien des startups qui démarrent tout juste leur aventure cloud.
Et je constate sans cesse les mêmes erreurs.
J'en partage ici quelques-unes, en espérant que vous saurez les éviter avant qu'elles ne deviennent coûteuses, douloureuses ou difficiles à corriger :
1\. Le compte AWS est ouvert avec l'adresse e-mail personnelle d'un fondateur
Bien souvent, le premier compte AWS est créé avec l'adresse Gmail privée d'un fondateur.
Dans ce cas, le compte appartient juridiquement et opérationnellement à une personne, et non à l'entreprise.
Si le fondateur quitte l'entreprise, qu'un conflit éclate ou (dans le pire des cas) qu'il lui arrive quelque chose, la propriété du compte devient un risque majeur pour l'activité.
Par ailleurs, une messagerie personnelle est généralement moins sécurisée qu'une boîte professionnelle : pas de MFA imposé, pas d'audit centralisé, une gouvernance des identités plus faible et un véritable obstacle lors d'un audit de certification.
Une compromission de l'adresse du fondateur signifie souvent un contrôle total sur l'environnement AWS de l'entreprise.
Cela crée également un point de défaillance unique.
Bonne pratique :
Créez une boîte e-mail de groupe partagée, par exemple : [email protected]
Ajoutez-y au moins deux membres de l'équipe (il y a toujours quelqu'un de malade, en vacances ou en conférence) et utilisez le plus-addressing pour distinguer les environnements entre différents comptes AWS :
2\. Créer des ressources dans le Management Account
Une startup démarre avec un compte AWS unique qui héberge tout : production, développement, démos et bac à sable des développeurs.
À mesure que l'entreprise grandit, il devient nécessaire de séparer les environnements. La voie la plus simple semble être de transformer ce compte unique en Management Account dans AWS Organizations, puis de créer de nouveaux comptes membres via l'organisation.
Le problème : le Management Account est le seul compte qui échappe aux contrôles applicables à l'ensemble de l'organisation.
Documentation des Service Control Policies d'AWS Organizations
Exemples de politiques que l'on souhaite généralement appliquer :
- Tous les volumes EBS d'EC2 doivent être chiffrés.
- Aucune ressource ne peut être créée dans des régions non autorisées.
- Les types d'instances coûteux (GPU) sont restreints.
- Les utilisateurs IAM sont interdits (seuls les rôles sont autorisés).
Aucune de ces règles ne s'applique au Management Account, qui, dans ce scénario, est aussi le compte de production.
Pire encore, AWS ne permet pas de convertir un Management Account en compte membre.
Une fois que le compte de production est aussi le Management Account, la seule solution est une migration organisationnelle complète : reconstruire l'organisation, recréer les politiques, reconfigurer les permissions et réintégrer chaque collaborateur sur un nouveau point d'entrée Single Sign On (SSO).
Si vous en êtes encore au stade où tout tourne sur un seul compte AWS et que vous souhaitez commencer à séparer les environnements, créez un nouveau compte AWS autonome, désignez-le comme Management Account via AWS Organizations, et invitez le compte de production existant à rejoindre la nouvelle organisation en tant que compte membre.
3\. Repousser la conformité à plus tard
Si vous prévoyez de vendre à des grands comptes, on finira par vous demander des certifications de conformité :
- SOC 2 / ISO 27001 pour le SaaS B2B
- HIPAA pour le secteur de la santé
- PCI DSS pour la fintech et les paiements
Adapter a posteriori un produit et une organisation existants à de nouvelles exigences de conformité est extrêmement difficile.
Cela touche non seulement l'architecture cloud, mais aussi les workflows de développement, le contrôle d'accès et jusqu'aux contrats de travail (propriété intellectuelle, confidentialité, gestion des terminaux, etc.).
Corriger l'infrastructure cloud est un défi, mais c'est faisable. Modifier les contrats et les processus organisationnels après coup est bien plus complexe. S'entourer d'un partenaire conseil en conformité dès les toutes premières lignes de code de votre produit simplifie donc considérablement le parcours.
4\. Tous les œufs dans le même panier
AWS permet de gérer l'enregistrement, le renouvellement et le DNS de votre domaine directement dans Route 53 : c'est pratique, et c'est risqué.
Si le compte AWS est suspendu (à la suite d'un problème de facturation, d'un incident de sécurité ou d'une clé IAM divulguée), votre domaine peut l'être aussi.
Or, lorsque l'e-mail cesse de fonctionner, il devient très difficile de communiquer avec le support AWS pour résoudre le problème.
publications de r/aws sur Reddit.com
Bonne pratique :
Conservez le domaine principal de l'entreprise en dehors du compte AWS de production, soit chez un registrar tiers comme GoDaddy ou NameCheap, soit dans un compte AWS dédié. Si vous êtes verrouillé hors de votre compte de production, vous pourrez toujours maintenir vos enregistrements DNS depuis l'autre fournisseur ou compte.
5\. Tenir un calendrier d'expiration pour ne manquer aucune date de renouvellement critique
Dès la première année, une startup accumule rapidement :
- Des contrats
- Des clés API
- Des cartes bancaires
Leur point commun : une date d'expiration.
Les conséquences fâcheuses sont généralement :
- Comptes AWS bloqués pour défaut de paiement.
- Interruptions de service inattendues dues à une clé API expirée.
- Renégociations de contrat dans l'urgence à cause de dates manquées ou imminentes.
Un calendrier partagé avec rappels automatisés (Carte bancaire 3344 expire dans 30 jours, Renouvellement du contrat MAP dans 45 jours) permet d'éviter ces écueils.
Pour conclure
Les défis sont nombreux. Je recommande vivement de trouver un mentor qui a déjà été fondateur et a piloté plusieurs startups. Les conseils d'un profil aguerri valent réellement de l'or.
Si vous voulez bâtir votre cloud sur des bases solides dès le premier jour, DoiT apporte la technologie, l'expertise et des années d'expérience pour aider aussi bien les startups que les grandes entreprises à éviter précisément ces erreurs — et bien d'autres.
Faisons de votre cloud un moteur de croissance, et non un facteur de risque.