Cloud & Infrastructure
Des déploiements sans surprise et une infrastructure que vous pouvez reconstruire
On reconnaît une équipe qui n’a pas adopté les pratiques DevOps à la façon dont elle parle des mises en production. Les déploiements ont lieu le vendredi après-midi, manuellement, avec quelqu’un qui surveille l’écran. Personne n’est certain que l’environnement de staging corresponde à la production. Quand un problème survient à 2h du matin, la première alerte provient d’un client. Les trois problèmes sont résolubles, et aucun ne nécessite de refonte complète du code.
Indicatif
Audit à partir de £3,000 ; configuration à partir de £6,000
Prix fixe convenu par écrit avant le début de la réalisation.
Demander un devis+44 7488 265083Le problème que cela résout
Déployer manuellement ne ralentit pas seulement le processus : cela transforme chaque mise en production en un pari risqué — d’où des lots de déploiement plus importants, et des risques qui s’accumulent. Par ailleurs, une infrastructure qui n’existe que sous forme de clics dans une console ne peut être revue, reproduite, ni même documentée. Elle disparaît avec la personne qui l’a configurée.
Ce que vous obtenez
Un pipeline contrôlé par les tests
GitHub Actions ou GitLab CI exécutant votre suite de tests, les vérifications de typage et une compilation à chaque push. Rien ne parvient en production sans validation préalable, ce qui fait du pipeline la norme plutôt qu’un rappel humain.
Infrastructure en tant que code
Terraform pour les ressources cloud, afin que chaque modification passe par une pull request revue, avec un plan lisible avant application. L’environnement devient reproductible au lieu d’être un chantier archéologique.
Des environnements réellement identiques
Un environnement de staging construit à partir des mêmes définitions que la production, avec des volumes de données suffisamment réalistes pour qu’une requête rapide en staging le soit aussi en production.
Mises en production sans interruption
Déploiements blue-green ou rolling avec vérifications de santé, et un retour arrière exécutable en une seule commande plutôt qu’une course contre la montre. Une mise en production que l’on peut annuler en 60 secondes cesse d’être effrayante.
Surveillance avec alertes pertinentes
Disponibilité, taux d’erreurs, temps de réponse et profondeur des files d’attente, avec des seuils ajustés pour que chaque alerte ait un sens. Un tableau de bord que personne ne consulte n’est pas de la surveillance ; une chaîne d’alertes ignorées est pire.
Revue des coûts
Instances dimensionnées au plus juste, capacité réservée lorsque l’usage est prévisible, et le stockage que personne n’a examiné depuis 2022. Réduire une facture cloud d’un tiers sans perte de performance est courant.
Notre méthode de travail
Audit
Comment vous déployez aujourd’hui, ce qui tourne où, ce qui est surveillé, et ce qui se passe en cas de panne. Généralement une semaine de travail, et le résultat est un document écrit que vous conservez quel que soit la suite.
Prioriser par le risque
Commencer par la correction qui élimine le plus de risques — ce qui est presque toujours moins spectaculaire qu’on ne l’imagine. Souvent, il s’agit de sauvegardes jamais restaurées ou d’un serveur unique sans plan de secours.
Commencer par le pipeline
Automatiser la compilation, les tests et le déploiement vers le staging avant que quoi que ce soit n’atteigne la production. C’est là que naît la confiance nécessaire pour modifier le reste.
Coder l’infrastructure
Importer l’existant dans Terraform, puis effectuer les modifications via cet outil. Pas de refonte brutale — le système en production continue de fonctionner.
Observabilité
Métriques, logs structurés et alertes, avec un système de rotation d’astreinte que vous validez.
Transfert de connaissances
Des procédures détaillées pour les pannes qui surviennent réellement, avec une présentation à la personne qui sera en première ligne en cas d'urgence.
Ce à quoi vous devez vous attendre
- Les déploiements passent d'un événement planifié à une opération courante
- Toute modification de l'infrastructure est revue avant application
- Les problèmes sont détectés par la surveillance plutôt que par les clients
- Les coûts d'hébergement sont réduits sans altérer les performances
Créé avec
- AWS
- Azure
- DigitalOcean
- Hetzner
- Terraform
- Docker
- Kubernetes
- GitHub Actions
- GitLab CI
- Nginx
- LiteSpeed
- Cloudflare
- Grafana
- Prometheus
- Sentry
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
Ingénierie DevOps & Cloud — your questions
Y compris les questions relatives au coût, que la plupart des agences omettent sur leur site.
La configuration d’un pipeline et d’une infrastructure-as-code pour une application web classique commence autour de £6 000, et un audit seul coûte entre £3 000 et £6 000. La gestion continue est chiffrée mensuellement en fonction de ce qui est réellement en production, et non sous forme de forfait fixe.
Probablement pas. Kubernetes résout des problèmes qui n'apparaissent qu'à une échelle que la plupart des PME britanniques n'atteignent jamais, et il engendre une charge opérationnelle réelle — quelqu'un doit le maîtriser à 2h du matin. Des conteneurs sur une plateforme managée gèrent la grande majorité des charges de travail avec une fraction de la complexité. Nous vous le dirons plutôt que de vous vendre une solution plus coûteuse.
Oui. La plupart de ces interventions sont indépendantes du fournisseur. Nous préférons améliorer ce que vous avez déjà plutôt que de vous faire migrer vers une nouvelle solution pour le simple plaisir de changer. Si votre hébergeur actuel est vraiment le goulot d'étranglement, nous vous le montrerons avec des chiffres.
À trois choses : chaque modification est vérifiable avant d’être appliquée, l’environnement peut être reconstruit à partir de zéro en cas de perte, et la configuration ne repose plus dans la tête d’une seule personne. Le troisième point est le plus important : c’est ce qui rend l’équipe remplaçable plutôt que le système fragile.
Le pipeline et les tests en staging s’exécutent en parallèle de la production et n’affectent pas ce que voient les utilisateurs. Les modifications en production sont testées, appliquées en dehors des heures ouvrées en cas de risque, et réversibles. Nous ne faisons pas de migrations en une seule fois.
Nous proposons en standard une réponse aux heures ouvrées pour les entreprises britanniques, avec une couverture hors heures ouvrées disponible en option payante. Nous sommes clairs sur ce point : une véritable astreinte 24/7 nécessite un roulement, et une seule personne prétendant assurer une couverture permanente n’est pas un vrai service.
Services associés
La plupart des projets touchent à plus d’un de ces services.
Gestion de serveurs
Correctifs, surveillance, sauvegardes réellement testées, et une personne désignée à contacter en cas de problème.
Lire la suiteMigration vers le cloud
Une migration par phases avec une bascule répétée et un retour arrière testé, et non simplement documenté.
Lire la suiteAudits de sécurité et renforcement
Un audit manuel avec preuve de concept fonctionnelle pour chaque résultat, un plan de correction priorisé, et un nouveau test confirmant la résolution.
Lire la suiteParlez à quelqu'un qui l'a déjà développé
A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.