Une infrastructure que vous pouvez reconstruire depuis un git clone.
Nous concevons, construisons et exploitons des environnements AWS pour des produits de petite et moyenne taille : chaque ressource en code, dev/staging/prod séparés dès le premier jour, des déploiements qui prennent quelques minutes, et une supervision qui dit la vérité.
Vous n'avez pas besoin de Kubernetes. Vous avez besoin d'environnements cohérents entre eux, d'un déploiement en qui vous avez confiance, de sauvegardes que vous avez réellement restaurées, et d'une facture AWS sans surprise. Nous avons écrit une série de 29 articles sur exactement ce sujet, car c'est ce que nous faisons chaque semaine pour nos propres produits et pour nos clients.
Notre standard est AWS CDK en TypeScript, des conteneurs sur ECS/Fargate ou App Runner, RDS ou Aurora, trois comptes sous une seule organisation, GitHub Actions avec OIDC (pas de clés longue durée), et une observabilité qui ne vous enferme pas chez un seul fournisseur. Quand votre plateforme est différente, nous nous adaptons ; les principes, eux, ne changent pas.
Conçu, déployé et exploité.
Architecture et structure des comptes
Landing zone, comptes dev/staging/prod, réseau, limites IAM et modèle de coût, dimensionnés pour ce que vous exploitez aujourd'hui et ce que vous exploiterez l'an prochain.
Infrastructure en code avec CDK
Chaque ressource en TypeScript, revue en pull request, déployée de la même façon sur chaque environnement. Pas de clics dans la console, pas de dérive.
Des conteneurs sans la taxe du cluster
ECS/Fargate ou App Runner pour les services web et les workers, images distroless, health checks qui veulent dire quelque chose, déploiements sans interruption de service.
CI/CD et environnements de prévisualisation
GitHub Actions avec des rôles OIDC par compte, des monorepos qui ne reconstruisent que ce qui a changé, un environnement de prévisualisation par pull request, des rollbacks en une commande.
Observabilité et préparation aux incidents
Logs, traces et alertes qui ne dépendent pas d'un seul fournisseur, des tableaux de bord que les gens regardent réellement, et un runbook pour une équipe sans astreinte.
Hygiène des coûts et de la sécurité
Passerelles NAT, savings plans, gestion des secrets, WAF, rotation sans interruption, sauvegardes testées en les restaurant réellement.
Ce que vous obtenez
- Une base de code CDK qui recrée tout votre environnement depuis un compte vide
- Des environnements dev, staging et production séparés, avec un chemin de promotion documenté
- Des pipelines CI/CD avec OIDC, environnements de prévisualisation et rollback
- Supervision, alertes et un runbook d'incident rédigé pour votre équipe
- Une revue de coûts avec des économies concrètes et le raisonnement derrière chacune
C'est fait pour vous si
- Votre infrastructure a été montée à la main et personne n'ose y toucher
- Les déploiements font peur, sont lents, ou sont faits par une seule personne qui ne peut pas partir en vacances
- Votre facture AWS a augmenté plus vite que votre trafic et vous voulez savoir pourquoi
Comment se déroule une mission
Vous obtenez un ingenieur senior qui livre comme une petite equipe — avec un taux horaire transparent, un reporting hebdomadaire et sans frais d'agence. Ajustez les heures a la hausse ou a la baisse selon les besoins du projet.
- 01Diagnostic — une semaine à examiner vos comptes, vos pipelines et vos factures ; vous recevez un rapport écrit avec des priorités.
- 02Fondations — comptes, réseau, squelette CDK, CI/CD avec OIDC, et le premier service déployé selon la nouvelle méthode.
- 03Migration — services et données déplacés environnement par environnement, avec un rollback possible à chaque étape et sans week-end big-bang.
- 04Exploitation — supervision, revues de coûts et support à la demande, ou une transmission propre à votre équipe avec formation.
Les questions qu'on nous pose avant chaque mission
Pourquoi pas Kubernetes ?
Pour la plupart des produits en dessous de quelques centaines de requêtes par seconde, ECS/Fargate ou App Runner offrent la même fiabilité avec une charge opérationnelle bien moindre. Nous utilisons Kubernetes quand il y a une vraie raison (équipe plateforme existante, charges de travail spécifiques), pas par défaut.
CDK ou Terraform ?
Sur AWS, nous préférons CDK en TypeScript : votre infrastructure et votre application partagent un langage, un relecteur et un test runner. Nous sommes tout à fait à l'aise avec Terraform quand vous l'avez déjà ou que vous êtes en multi-cloud. L'infrastructure en code est l'exigence ; l'outil est un choix.
Pouvez-vous nous faire migrer sans interruption de service ?
En général, oui. Nous migrons environnement par environnement, gardons l'ancien chemin actif jusqu'à ce que le nouveau soit vérifié, et traitons les migrations de schéma comme une discipline plutôt que comme un événement. Vous connaîtrez le risque de chaque étape avant que nous la franchissions.
Assurez-vous une astreinte ?
Nous fournissons supervision, alertes et un runbook conçus pour une équipe qui n'a pas d'astreinte, ainsi qu'un support à la demande pendant les heures ouvrées. Nous ne vendons pas de couverture pager 24/7 ; nous construisons pour que vous en ayez rarement besoin.
Combien pouvons-nous économiser sur AWS ?
Cela dépend de ce qui ne va pas. Les constats typiques sont des passerelles NAT inactives, des volumes non attachés, des bases de données surdimensionnées, l'absence de savings plans et des logs conservés indéfiniment. Nous vous présentons chaque économie avec le raisonnement, pour que vous puissiez décider.
Notre point de vue
Comment nous construisons le cloud et le DevOps : trois comptes, une base CDK, et aucun cluster
Nous exploitons AWS pour nos propres produits et pour une plateforme cliente avec de vrais utilisateurs et de l'argent r...
septembre 2026
Dev, staging et prod dès le premier jour : pourquoi une équipe de trois ne devrait pas attendre
« On séparera les environnements plus tard, quand on aura des utilisateurs. » Nous avons entendu cette phrase de chaque...
septembre 2026
Vous n'avez pas besoin de Kubernetes. Vous avez besoin d'un bon Dockerfile et d'un endroit pour le faire tourner.
Tous les quelques mois, une équipe de trois à cinq ingénieurs nous demande si elle devrait passer à Kubernetes. L'applic...
septembre 2026Besoin d'une infrastructure en qui vous pouvez avoir confiance ?
Missions flexibles horaires / time-and-materials, 100% remote, B2B. Communication directe avec l'ingenieur qui fait le travail — sans intermediaires, sans discours commercial.