Pôle DevOps & Cloud
DevOps et cloud : une mise en production qui n'inquiète plus personne
Un bon système de déploiement se reconnaît à ceci : plus personne n'en parle. Il s'exécute en pleine journée, il est réversible, et il ne mobilise pas trois personnes un vendredi soir.
Beaucoup d'organisations ont migré vers le cloud sans changer leur façon de déployer. Le résultat est une infrastructure louée à l'heure mais gérée à la main : les coûts augmentent, la reproductibilité n'existe pas, et la connaissance reste dans la tête d'une ou deux personnes.
Notre critère de fin de mission est simple et vérifiable : un environnement complet doit pouvoir être détruit et reconstruit à l'identique à partir de votre dépôt. Tant que ce n'est pas vrai, l'industrialisation n'est pas terminée, quel que soit le nombre d'outils installés.
Les symptômes que nous voyons le plus souvent
- Les mises en production ont lieu le soir ou le week-end, et mobilisent plusieurs personnes
- Personne ne sait reconstruire un environnement depuis zéro
- La facture cloud augmente sans que personne puisse expliquer quelle ligne
- La supervision se limite à vérifier que la machine répond
- Les sauvegardes existent mais la restauration n'a jamais été testée
- Une seule personne détient les accès critiques
Notre façon de traiter le sujet
La trajectoire avant le schéma cible
Un schéma d'architecture cible est facile à produire et n'engage personne. Ce qui compte est la séquence : quelle brique bouge d'abord, où se situe le point de non-retour, et comment revenir en arrière à chaque étape.
Le test de restauration, réellement exécuté
Une sauvegarde non restaurée n'est pas une sauvegarde. Nous exécutons une restauration complète et nous la chronométrons, ce qui donne votre vrai délai de reprise plutôt que celui figurant dans la procédure.
Des alertes reliées à des runbooks
Une alerte qui n'indique pas quoi faire finit ignorée en quelques semaines. Chaque alerte que nous mettons en place pointe vers une procédure écrite, et celles qui n'en méritent pas sont supprimées.
Recommander la solution la plus simple, même quand elle nous dessert
Kubernetes se justifie à partir d'un certain nombre de services et d'une équipe capable de l'exploiter. En dessous, un service applicatif managé coûte moins cher et casse moins souvent. Nous le déconseillons régulièrement, alors que ce serait une mission plus longue à vendre.
Les services de ce pôle
Questions fréquentes
Combien peut-on économiser sur une facture cloud ?
Cela dépend entièrement de votre point de départ, et il faut se méfier de tout pourcentage annoncé avant lecture de la facture. Les postes les plus souvent concernés sont le dimensionnement des instances, les ressources orphelines, les environnements hors production laissés allumés et la rétention des journaux. L'audit chiffre chaque poste séparément.
Faut-il tout migrer d'un coup ?
Non, sauf contrainte de date sur un centre de données. Une migration par vagues, avec double run et point de retour arrière à chaque étape, coûte un peu plus cher et échoue beaucoup moins souvent. Les migrations en un seul week-end réussissent surtout dans les présentations commerciales.
Assurez-vous l'astreinte ?
En heures ouvrées dans le cadre d'un contrat de TMA, oui. Une astreinte étendue se contractualise séparément, avec un périmètre et des engagements écrits. Nous ne proposons pas d'infogérance de premier niveau seule : ce n'est pas notre métier et le faire mal serait pire que ne pas le faire.
Vingt minutes suffisent pour savoir si nous sommes utiles
Aucune présentation commerciale. Vous décrivez votre besoin ; nous vous disons s'il entre dans notre périmètre, dans quel délai et à quel budget. Si ce n'est pas pour nous, vous le saurez pendant l'appel.