L'agile en agence web

La méthode agile est une approche itérative dans la gestion de projet, où l'équipe fournit régulièrement un livrable fonctionnel et adapte son plan en fonction des retours, plutôt que de suivre une spécification fixée à l'avance. Scrum, Kanban et Scrumban en sont les principaux cadres.

L'agile en agence web prend la forme de sprints (généralement de deux semaines), de quatre principaux rituels (planification, stand-up quotidien, revue, rétrospective) et d'un décideur unique côté client (le product owner). Chaque sprint fonctionne comme un mini-forfait, où les deux parties s'accordent sur le backlog au démarrage et figent les priorités jusqu'à la fin du cycle.

Un sprint commence par une planification (sprint planning) où nous nous accordons sur ce qui sera livré. L'équipe travaille pendant dix jours ouvrés, se synchronise quotidiennement, démontre un incrément fonctionnel (increment) à la revue, et conduit une rétrospective. Le livrable est un fragment du projet déployable et examinable.

Ce qu'est l'agile, concrètement

Adopter l'agile commence par accepter qu'un projet ne tient jamais entièrement dans un cahier des charges initial. Mieux vaut livrer tôt pour apprendre des utilisateurs réels et ajuster en cours de route que planifier exhaustivement avant d'agir.

Les cadres comme Scrum, Kanban ou Scrumban mettent cette logique en pratique, chacun répondant à une question différente : Scrum cadre la cadence et les rituels, Kanban fluidifie un flux de travail, Scrumban réconcilie les deux.

L'agile en agence web : ce qui change quand l'équipe est externe

Quand l'équipe agile est externe plutôt qu'interne, l'engagement devient commercial. Un sprint engage à la fois l'agence sur le contenu du backlog convenu et le client sur sa disponibilité comme sur le non-changement des priorités. Le périmètre, lui, dérive plus rapidement, parce que le client n'est pas dans la pièce tous les jours et qu'une demande qui aurait été un échange de cinq minutes en interne devient une requête formelle.

C'est pourquoi nous traitons chaque sprint comme un mini-forfait dont le backlog s'arrête au démarrage. Les nouvelles demandes nourrissent le sprint suivant, pas l'actuel, ce qui protège la qualité du travail comme la prévisibilité de la livraison.

Cette logique se distingue de la régie, où le développeur intègre votre équipe et suit votre cadence, alors qu'en agile au forfait c'est notre équipe qui pilote le sprint avec votre product owner.

Comment nous structurons un sprint

Un sprint dure deux semaines et s'organise autour de quatre rituels qui rythment les dix jours ouvrés. Au démarrage, une planification cadre le travail à venir ; un stand-up quotidien maintient l'équipe synchronisée pendant le cycle. La revue avec les parties prenantes en marque la fin, suivie d'une rétrospective interne qui prépare le sprint suivant.

Les quatre rituels (ceremonies) de chaque sprint :

• Planification de sprint (sprint planning) (1 à 2 heures, équipe et product owner) : nous accordons ce qui sera livré. Le backlog du sprint (la liste des tâches retenues pour le cycle) est figé à la fin de la réunion.
• Stand-up quotidien (15 minutes, équipe) : trois questions, ce que j'ai fait hier, ce que je fais aujourd'hui, ce qui me bloque. Le format est asynchrone par défaut, sauf si un blocage demande une réponse immédiate.
• Revue de sprint (sprint review) (30 à 60 minutes, équipe et parties prenantes) : nous démontrons l'incrément fonctionnel, c'est-à-dire la partie du produit terminée pendant le sprint. Pas de slides, un produit qui fonctionne.
• Rétrospective (sprint retrospective) (30 à 60 minutes, équipe seule) : ce qui a fonctionné, ce qui n'a pas, ce que nous changeons au prochain sprint.

La cadence de deux semaines s'est imposée dans les agences web. Elle laisse à l'équipe assez de temps pour produire entre deux planifications, sans laisser un mauvais cap durer plus de quinze jours avant d'être corrigé par les retours. Trois semaines fonctionnent dans certains contextes particuliers.

Le rôle du client dans ce modèle

Le client n'est pas spectateur. Il assume le rôle de product owner, ce qui implique de définir les priorités, d'arbitrer quand l'équipe a besoin d'une clarification, et de valider le résultat à chaque revue. Sans product owner désigné et disponible, le sprint dérive.

Concrètement, « disponible » suppose un délai de réponse d'environ vingt-quatre heures ouvrées, ainsi que la présence assurée aux trois rituels qui le concernent (planification, revue, rétrospective). Un product owner par procuration, qui transmet les questions sans pouvoir décider, n'est pas un product owner mais un canal supplémentaire qui ralentit les décisions. Quand cette autorité manque, les décisions traînent, le périmètre glisse, et l'équipe finit le sprint sans atteindre son objectif.

Là où l'agile dérape avec une agence

Plusieurs situations récurrentes affaiblissent l'agile dans un contexte agence :

• Un périmètre flou au démarrage. Sans une expression de besoin solide, chaque sprint commence par renégocier ce qui n'a pas été tranché au cadrage.
• Des parties prenantes lointaines ou désengagées. L'équipe construit la bonne chose seulement si les personnes qui savent à quoi ressemble la bonne chose participent aux revues.
• Des chaînes de validation plus longues qu'un sprint. Quand un livrable attend trois semaines pour être signé, l'élan du sprint est cassé avant d'être réinvesti.
• Le sprint traité comme une usine à fonctionnalités. Si chaque sprint repart de zéro sur le périmètre, l'équipe ne capitalise jamais sur ce qu'elle a appris au sprint précédent.

Quand agile et forfait coexistent

Beaucoup de projets web combinent les deux modèles. Une équipe agile pilote l'évolution courante d'une plateforme (sprints, incréments réguliers), tandis qu'une prestation au forfait prend en charge un chantier au périmètre verrouillé (migration, refonte, intégration spécifique). Ce schéma fonctionne parce qu'il fait jouer chaque modèle sur son point fort, l'agile prenant en charge l'incertitude et l'apprentissage tandis que le forfait porte un livrable défini avec un budget et un délai contractualisés.

Les deux cohabitent à condition que les frontières restent nettes, c'est-à-dire que le forfait n'absorbe pas les évolutions courantes et que l'agile ne récupère pas les chantiers structurants à mi-parcours.

Un troisième modèle existe, dans lequel la prestation reste au forfait avec une spécification signée mais l'exécution est organisée en sprints. L'équipe découpe le cahier des charges en incréments, livre par cycles courts, et conserve les rituels de planification, de revue et de rétrospective. Le client garde la sécurité d'un périmètre contractuel, l'équipe garde la cadence et la qualité de livraison de l'agile.

Ce modèle fonctionne quand la spécification est complète dès le départ. Quand elle ne l'est pas, les retours des sprints peuvent toujours faire évoluer le périmètre, mais par un avenant. Sur un projet récent, après quelques sprints livrés, le client a constaté que certaines fonctionnalités spécifiées ne correspondaient plus à son besoin. La résolution n'a pas été absorbée par le sprint en cours. Il a donc été décidé d'un complément au cahier des charges et d'un avenant couvrant les changements et les fonctionnalités nouvelles, signé avec un budget et un délai supplémentaires.

À retenir

• L'agile est une approche itérative ; Scrum, Kanban et Scrumban sont les cadres qui la mettent en pratique.
• Dans une agence web, un sprint de deux semaines fonctionne comme un mini-forfait avec backlog figé au démarrage.
• Quatre rituels structurent chaque sprint : planification, stand-up, revue, rétrospective.
• Le client tient le rôle de product owner : disponible, décisionnaire, validant à chaque revue.
• L'agile et le forfait se combinent bien quand les frontières entre incertitude et livrable verrouillé sont nettes.

Questions fréquentes

Qu'est-ce que l'agile en développement web ?

L'agile est une approche itérative qui consiste à livrer un projet web par incréments courts (typiquement de deux semaines) en intégrant les retours du client à chaque cycle, plutôt que de viser une livraison unique à la fin d'un cahier des charges figé.

Combien de temps dure un sprint dans une agence web ?

Deux semaines est la durée standard. Une semaine génère trop de coûts de planification, trois semaines retardent les retours et laissent durer les mauvaises décisions. Toutefois, dans des cas très particuliers, on peut préférer des sprints de trois semaines.

Qu'est-ce qu'un product owner dans une mission agile ?

Le product owner est la personne côté client qui définit les priorités, arbitre les questions et valide le résultat à chaque revue de sprint. Sans product owner désigné et disponible, le sprint perd son cap.

Vaut-il mieux faire de l'agile ou du waterfall pour un projet web ?

La question est mal posée. La vraie question est de savoir si votre périmètre est stable ou amené à évoluer en cours de projet. L'agile convient aux projets dont le périmètre évoluera avec l'apprentissage et les retours utilisateurs. Le waterfall reste pertinent lorsque le périmètre est verrouillé d'avance et que les itérations apporteraient peu de valeur (contexte réglementaire, équipement critique).

Que se passe-t-il si le client n'est pas disponible pendant le sprint ?

Les décisions sont différées, le périmètre du sprint glisse, et l'objectif du sprint n'est pas atteint. L'équipe peut signaler que l'autorité de décision côté client manque, mais elle ne peut pas s'y substituer.

Peut-on combiner agile et forfait ?

Oui, et c'est courant sur les projets web complexes. Une équipe agile gère l'évolution courante de la plateforme tandis qu'une prestation au forfait prend en charge un chantier au périmètre verrouillé. Un troisième schéma consiste à conduire un forfait au cahier des charges signé avec une exécution en sprints, ce qui suppose un cahier des charges bien défini dès le départ.

En quoi l'agile en agence diffère-t-il de l'agile chez un éditeur de produit ?

Dans une agence, le sprint est un engagement commercial entre deux parties, où l'agence s'engage sur le contenu du backlog tandis que le client s'engage sur sa disponibilité et le non-changement des priorités. Chez un éditeur, ces tensions existent moins parce que l'équipe et le commanditaire appartiennent à la même organisation.

Si vous évaluez l'agile en agence web pour votre prochaine mission, notre service de conseil et accompagnement est conçu pour cette phase. Et si vous êtes prêt à démarrer un projet de développement web, contactez-nous.

Keroberos accompagne les projets web en mode agile. Pour discuter de vos besoins, prenez contact avec nous.