Architecture serverless et Scrum : livrer sans gérer l'infrastructure
Dans un modèle serverless, le code est déployé comme des fonctions discrètes déclenchées à la demande par des événements. Le fournisseur cloud gère les serveurs sous-jacents, l'environnement d'exécution et le dimensionnement automatique. L'équipe écrit des fonctions ; l'infrastructure se gère en grande partie elle-même. Pour les équipes Scrum, ce n'est pas seulement un changement technique : cela modifie la structure du travail, la planification des sprints, la définition de « terminé » et la localisation des nouveaux risques.
Comment le serverless modifie la planification des sprints
La réduction du travail de gestion d'infrastructure est réelle et significative. Mais le serverless introduit de nouvelles catégories de travail à planifier : la latence au démarrage à froid (cold start) pour les applications à exigences de latence, les limites de délai d'exécution des fonctions (15 minutes maximum sur AWS Lambda), le coût à l'échelle selon le modèle de facturation à l'invocation, et le risque de dépendance au fournisseur (vendor lock-in) lié aux API spécifiques aux plateformes.
La définition de « terminé » dans un contexte serverless
Une définition de « terminé » adaptée au serverless doit inclure des critères dans plusieurs domaines : monitoring et alertes en place avant la fin du sprint (métriques d'invocation, taux d'erreurs, distributions de durée), visibilité sur le coût par fonction via des tags d'allocation, tests de performance aux volumes de production attendus (comportement au cold start sous charge, limites de concurrence), et gestion des erreurs avec files d'attente de lettres mortes pour les fonctions traitant des événements en file d'attente.
Ce que le Scrum Master et le Product Owner doivent savoir
Le Scrum Master doit comprendre que le serverless introduit de nouvelles catégories de travail technique qui appartiennent à la définition de « terminé » et à la planification des sprints. Un Scrum Master qui les traite comme optionnelles crée involontairement de la dette technique et du risque opérationnel à chaque sprint. Le Product Owner doit comprendre le modèle de coût suffisamment pour prendre des décisions de priorisation éclairées : dans une architecture serverless, chaque fonctionnalité a un coût opérationnel incrémental qui évolue avec l'usage.
XNM Conseil travaille avec les équipes Scrum sur les pratiques de livraison agile, les méthodes de travail techniques et l'intégration de patterns d'architecture modernes dans des modèles de livraison efficaces. En savoir plus sur nos services de livraison de programmes et de projets.