SEO et Méthode Scrum Agile

De nombreux projets web sont aujourd’hui gérés grâce à la méthode Scrum Agile. Aussi, les responsables SEO en entreprise se doivent de comprendre les tenants et aboutissants de cette méthode afin de mener à bien les projets en termes d’optimisation du site pour les moteurs de recherche et de ne pas risquer que certaines fonctionnalités SEO passent « à l’as ». Dans cet article, après une explication de ce qu’est cette méthode, nous aborderons les spécificités du SEO en termes de méthodologie Scrum Agile.

 

Une bonne gestion de projets est indispensable pour obtenir des résultats en SEO. En effet, si optimiser efficacement un site pour les moteurs de recherche exige un savoir certain et une bonne dose de savoir faire, dans de nombreux contextes il faut également savoir… Faire faire par les autres les optimisations dont vous avez besoin.

En pratique, cela passe par le fait de bien maîtriser la gestion de projets informatiques. Or pour les sites web, une méthode de gestion de projet s’est imposée : la méthode Scrum Agile. Nous allons donc développer dans cet article les bonnes pratiques pour intégrer les optimisations SEO dans un projet géré en Scrum Agile, mais aussi les limites de la méthode et les principaux pièges à éviter. Et nous finirons en rappelant que dans la plupart des cas, les spécifications fonctionnelles ne sont pas réellement gérées en méthode Agile, et ce que cela implique pour les aspects SEO d’un projet Web.

Fig. 1. Le nom de la méthode Scrum est tiré du… rugby.
La « mélée » (scrum) est le nom choisi pour la réunion quotidienne entre les développeurs.

Vous avez dit Agile ?

Dans les années 70 et 80 la plupart des projets informatiques étaient gérés avec une méthode dite en cascade (waterfall), ou sous une version améliorée dite « cycle en V  », car les étapes suivies étaient souvent représentées sous la forme d’un diagramme en V. L’idée de base était de suivre un processus rigoureux permettant de passer progressivement de l’idée à une expression de besoin formalisée, puis à des spécifications détaillées pour entrer ensuite dans des phases de développement. Les phases de recettes et de tests permettaient ensuite de s’assurer que le produit développé correspondait bien aux spécifications.

Fig. 2. L’approche « en cascade » : chaque étape doit être achevée pour commencer la suivante.

Même si cette méthode avait contribué au succès de projets comme le programme Apollo, le cycle en V avait des inconvénients que les informaticiens ont identifié très tôt :

• Beaucoup de temps était perdu dans la rédaction de spécifications, qui pour des projets complexes aboutissait à des centaines de pages à lire par les développeurs ;
• La complétion de toutes les étapes demandait beaucoup de temps, ce qui conduisait parfois à sortir des produits déjà obsolètes avant d’être lancés ;
• On partait du principe que ceux qui avaient rédigé les spécifications savaient exactement ce qu’ils voulaient, savaient anticiper le résultat final et ne commettaient aucune erreur de conception ou de rédaction, ce qui dans la réalité se révèle souvent parfaitement faux.

Fig. 3. La méthode dite du cycle en V : à chaque étape de la cascade une phase de test est prévue, qui est effectuée en remontant en commençant par les tests unitaires jusqu’à la la validation finale (d’où le schéma en forme de « V »).

Avec la montée en puissance d’Internet et des nouvelles technologies, ces défauts sont apparus comme réellement handicapants, et de nouvelles façons de gérer les projets sont apparues progressivement. En 2001, le « manifeste Agile » a défini pour ces méthodes le concept d' »agilité ». Les méthodes dites « Agile » comprennent notamment :

• La méthode RAD (Rapid Application Dévelopment) ou son équivalent au Rouame-Uni : DSDM ;
• L’Extreme Programming (XP) ;
• Et la méthode Scrum, ou Scrum Agile, la plus populaire pour les projets Internet.

La méthode Scrum Agile en bref

La description de la méthode Scrum Agile dépasse de loin le cadre de cet article. Pour résumer, elle se caractérise par un découpage du projet en cycle de développement courts : les Sprints. Un Sprint est classiquement une période de deux semaines, mais on voit aussi plus court (une semaine) ou plus long (trois semaines, un mois). A l’issue de chaque sprint, des tests et des recettes sont effectuées pour s’assurer que le produit fini est ok.

La méthode met l’accent sur une documentation très allégée, et centrée sur les besoins utilisateurs. Les expressions de besoins sont organisés sous forme de documents courts, un par fonctionnalité, qui sont appelées « user stories » (récits utilisateurs ou scénarios client en français). L’ensemble des user stories non encore développées constituent ce qu’on appelle le « backlog ».

Fig. 4. Représentation du déroulement des phases de développement en scrum agile.

La communication entre tous les acteurs du projet est favorisée. Des réunions régulières sont organisées, notamment les fameuses « mêlées  qui sont censées être journalières ou les revues de sprint ou de backlog.

Traditionnellement, les scrums sont organisées en début de matinée, debout devant un tableau découpé en colonnes ou chaque post-it représente une user story et chaque colonne le niveau d’avancement du développement de chaque ticket. Ce tableau (le scrum board) est maintenant souvent « virtualisé » et suivi via des outils comme Trello, ou Jira ou l’un des nombreux autres outils du marché.

 

Fig. 5. Le « Scrum Board » avec ses différentes colonnes et ses « post it ».

Les raisons de la popularité de Scrum Agile pour les projets internet

Trois raisons expliquent pourquoi Scrum Agile est aussi populaire pour les projets web :

• La légèreté de la documentation produit est bien adaptée pour un projet web : en effet, une maquette et quelques lignes peuvent suffire pour décrire une page web et un développeur saura quoi faire (c’est parfois hélas la source de bien des déboires en SEO, la plupart des prérequis SEO étant invisibles dans les maquettes) ;
• Les donneurs d’ordre ne savent pas toujours ce qu’ils veulent : montrer un prototype vite fait permet d’avancer vers un produit finalisé par itération successive ;
• Un projet de type site web se découpe bien en user stories et en sprints.

La conséquence, c’est que la plupart des équipes de développement web ont pris l’habitude de travailler en méthode Scrum Agile. C’est aussi clairement un phénomène de mode alimenté par tout un écosystème.

Pour s’assurer qu’un projet web respectera les prérequis SEO, il faut donc s’intéresser de plus près à la manière dont on peut s’assurer du respect des contraintes SEO dans un projet Agile.

SEO et Scrum Agile

Les enjeux liés au SEO dans un projet web sont de deux ordres :

• Fonctionnels : s’assurer que le produit fini est « SEO compliant », conforme aux bonnes pratiques et optimisé ;
• Techniques : s’assurer que le nouveau code est correct, qu’il ne pose pas de problèmes de crawlabilité ou d’indexabilité, et qu’il est performant (rapide à télécharger).

Par ailleurs, il est important de vérifier que les changements apportés n’ont pas d’effets de bord (on casse quelque chose qui marchait avait) ou ne génèrent pas de régressions (on fait réapparaître un bug qui avait été déjà corrigé.

La conformité fonctionnelle est assurée par la bonne rédaction des spécifications (les « user stories »), et par des recettes fonctionnelles rigoureuses, mais aussi par une bonne gestion du backlog et des sprints.

La conformité technique se gère par des revues de code, des recettes techniques adaptées, et des tests de non régression.

Le rôle du Scrum Master et du Product Owner

On peut définir deux rôles clés dans la méthode Agile : le Product Owner et le Scrum Master.

Le responsable produit (« Product Owner ») est en charge de la définition du produit fini attendu : c’est lui qui rédige les « user stories ». En pratique, c’est souvent le maillon faible dans un projet Agile. Pour qu’il soit pleinement efficace, il a besoin de bien maîtriser la méthodologie Agile et connaître un minimum la technique pour parler le bon langage aux développeurs : c’est essentiel pour rédiger des user stories précises, anticiper les questions, contrôler le résultat final et détecter les dérives. Sauf qu’en pratique, le product owner est parfois quelqu’un du marketing et c’est le Scrum Master qui se retrouve forcé de rédiger les user stories, ce qui est une hérésie.

Car le rôle du Scrum Master est tout autre : c’est lui qui organise le travail, non pas comme un chef de projet, mais comme un chef d’orchestre qui indique la cadence (le découpage en sprints), organise les réunions (les fameuses « mêlées », mais aussi les revues de sprint), et qui fait les retours sur le déroulement des sprints.

La maîtrise et le respect de la méthodologie Agile par le Scrum Master est clé dans la réussite d’un projet dit « Agile ».

L’analyse du backlog

Une erreur fréquemment commise par les spécialistes SEO est de considérer que toutes les user stories déjà présentes dans le backlog ne les concernent pas et qu’ils vont rédiger leurs propres user stories SEO (ou pire, laisser quelqu’un d’autre les rédiger).

En réalité, il est vital de lire TOUTES les user stories du Backlog pour :

• Détecter toutes celles qui ont un impact SEO potentiel (par exemple : changement d’URL, modification de la navigation, création/suppression de pages, changement du code HTML…) ;
• Repérer les endroits où il serait pertinent d’apporter des compléments pour assurer que le produit fini sera compatible avec les bonnes pratiques SEO.

Une fois cette analyse réalisée, il est utile de constituer une liste des user stories ayant un impact sur le SEO, cela permet de savoir si un Sprint de développement nécessite une recette pour les points SEO ou non, et de s’organiser en conséquence.

Certains outils du marché permettent de recevoir des alertes en cas de modification sur une user story. Il convient, en tant qu’expert SEO, de se mettre en destinataire de ces alertes pour les tickets ayant un impact SEO, même mineur, même s’il s’agit juste d’un risque de régression (ex : changement cosmétique sur un modèle de page qui conduira forcément à un changement du code HTML/JS/CSS).

La rédaction des User Stories

Les optimisations SEO ou les fonctionnalités utiles pour le SEO doivent être spécifiées avec rigueur dans les User Stories. Pour éviter le phénomène de déscopage que nous détaillerons plus loin, il est important :

• De ne créer de « user stories » spécifiques pour des besoins SEO que si c’est absolument nécessaire : il faut intégrer les optimisations SEO dans les autres user stories. Cela conduit à répéter parfois les mêmes specs dans plusieurs endroits, mais cela garantit la prise en compte des contraintes SEO lors du développement associé à chaque user story ;
• Pour les user stories « SEO », il est important de travailler l’argumentaire sur le bénéfice attendu de telle ou telle demande.

Fig. 6. Un exemple de modèle de « user story ».

Le découpage en sprints

C’est l’un des rôles du Scrum Master – en liaison avec le Product Owner – de décider des User Stories qui seront développées au cours d’un sprint. Les logiques de regroupement au sein d’un Sprint sont assez diverses selon les étapes d’un projet et sa nature.

On verra plus loin que surveiller ce
découpage en sprints est essentiel pour éviter que le développement de certaines fonctionnalités SEO passent à la trappe.

Fig. 7. Méthode de découpage d’un backlog de projets en sprint : on notera qu’un grand nombre d’items n’ont pas été retenus, la mise en production numéro 1 n’aboutira pas à l’achèvement de la moitié des fonctionnalités prévues.

Les revues de code

Il est impératif de vérifier la qualité du code développé dans un projet Scrum Agile. Nous verrons plus loin pourquoi. Evidemment, pour le spécialiste SEO employé sur le projet (interne ou externe) il n’est pas question de se plonger dans le code côté serveur (PHP, ASP Net, Java Python…)
.
Par contre, vérifier la qualité de ce qui est produit en HTML/JS/CSS est primordial.

N’attendez pas la fin du projet pour vérifier ce que cela donne : il sera sinon trop tard, et vous ne parviendrez pas à faire refaire les développements.

Il convient de vérifier les choses plus en amont :

• Repérez le premier sprint « front » : ceux au cours desquels les développeurs vont créer le code qui fabriquera les pages indexables par les moteurs de recherche. Si les premiers sprints sont consacrés au développement du back office, la qualité du code à cet endroit ne vous concernera pas en général.
• Demandez aux développeurs de vous laisser voir ou tester le code HTML généré par leur code. Si vous voyez des problèmes (une zone importante en Ajax, un problème d’URL, des balises SEO importantes manquantes, des balises non renseignées, etc.), il sera plus profitable de faire un retour tout de suite. Les mêmes erreurs ne seront pas reproduites par les développeurs sur les autres modèles de page : on maximise les chances que le code sera finalement SEO Compliant.

Généralement, obtenir une revue de code est assez mal reçu par les développeurs. Jusqu’à ce qu’il comprenne que vous leur faites gagner du temps pour la suite, et que surtout vous les aidez à satisfaire le donneur d’ordre. Soyez fermes, convaincants, et pédagogues !

Les recettes techniques et fonctionnelles

Dans la méthode Agile, chaque sprint est suivi de tests pour vérifier la conformité des développements aux « user stories ». Ce sont des mini recettes fonctionnelles et/ou techniques.

Dans la pratique, les bugs sont remontés à l’aide d’un outil de ticketing comme Redmine, ou l’un des nombreux outils de gestion de projet « Agile ».

Ces recettes sont d’autant plus efficaces côté SEO s’il a participé activement à la rédaction des users stories contenues dans le sprint recetté : impliquez-vous !

Les pièges de la méthode agile et comment les éviter

Dès qu’un projet est important et/ou qu’on instaure des « deadlines » (des dates limites à ne pas dépasser), les équipes de développement se retrouvent avec des ressources limitées mobilisables sur un nombre de sprints défini. Si le backlog (la liste des fonctionnalités à développer) est trop important pour être achevé dans le temps imparti, les Scrum Masters sont confrontés à un dilemne :

• Soit ils essaient de développer plus vite, au détriment de la qualité. Dans certains cas, cela conduit à des fonctionnalités qui sont retoquées lors des recettes, et la « user story » va déborder sur le sprint suivant, ce qui renforce l’engorgement. Dans la plupart des cas, on obtient « juste » un code bâclé, non conforme aux bonnes pratiques, incluant hélas celles du SEO (mais pas que…).
• Soit ils décident de ne pas développer finalement certaines fonctionnalités, au risque à la fin d’avoir un produit fini très inachevé et imparfait. Dans le jargon de développeur, on parle de « déscopage » : on sort du périmètre du projet tout ce qui n’apparait pas comme essentiel. Devinez ce qui est souvent « déscopé » : tout ce qui relève du SEO.

Limiter les problèmes liés à la qualité du code : la charte qualité ou l’assurance qualité et son contrôle

En pratique, la solution pour éviter que la qualité du code produit soit dangereusement sacrifié, le donneur d’ordre a tout intérêt à rédiger un document précisant ses exigences en la matière. Pour le SEO, on rappellera par exemple que :

• Toute page HTML doit comporter une balise <title> et cette balise doit être non vide.
• Toute URL suit STRICTEMENT la convention de nommage définie pour le projet, et la relation URL / page de contenu est unique et univoque dans les deux sens.
• Les contenus identifiés comme « SSR » sur les modèles de page doivent être générés côté serveur et pas côté browser.
• etc…

Ce document ne doit pas être un cours de SEO, mais une suite de règles claires qu’un développeur peut suivre. Et il faut obtenir que le développeur s’engage à le respecter.

Notez bien qu’au passage, fixer des objectifs de performance web et faire attention à la présence du data layer et des tags analytics sont également des points classiques à faire figurer dans cette « contrat de qualité ».

Comment éviter que le SEO soit sorti du périmètre d’un projet Agile ?

Pour éviter le déscopage, trois mesures simples suffisent en général à prévenir le problème :

1. Ne pas créer de user story identifiée « pour le SEO », sauf nécessité absolue (comme par exemple les specs sur le sitemap XML ou le robots.txt). Ne pas mentionner l’objectif SEO de certains ajouts si la fonctionnalité produit également une amélioration de l’UX, l’accessibilité, l’intérêt de la page, la conversion…).
2. Suivre attentivement le choix des user story incluses dans chaque sprint et contester toute dépriorisation des tickets SEO. L’idéal, c’est d’assister aux réunions de définition des sprints.
3. Et préparer une bonne argumentation pour défendre vos user stories et fonctionnalités SEO : pourquoi c’est important, quel est l’impact attendu ou le risque ou la perte d’opportunité si ce n’est pas fait. Et pourquoi c’est simple à faire éventuellement.

 

Pour éviter les dérives du déscopage : le produit minimum viable

Sur un projet complexe ou important (un lancement de site web ou une refonte par exemple), il est important de s’entendre avec l’équipe de développement sur la liste des fonctionnalités qui constitueront le Produit Minimum Viable (MVP en anglais).

Le MVP constitue la liste des fonctionnalités « sacrées » qu’il sera interdit de déscoper : mettre en production la nouvelle version sans l’une de ces fonctionnalités est défini comme inacceptable. Même si une deadline est définie, tout le monde sait que si elle est atteinte sans que tout le MVP soit développé, il faudra un sprint de plus, et la date de lancement devra être décalée.

Evidemment, on s’attachera à faire entrer dans ce MVP les fonctionnalités SEO importantes (avoir un générateur de sitemap XML automatique peut sortir du MVP, le robots.txt ou le générateur de hreflang pour un site international : c’est moins sûr…)

Les limites de la méthode Agile

Tout irait pour le mieux dans le meilleur des mondes Agile si la méthode était réellement suivie à la lettre par les équipes de développement. En fait, c’est rarement le cas, et il n’est pas rare de voir des projets gérés en « waterfall » présentés comme des projets Agiles, ou des principes fondamentaux de la méthode foulés au pied par les acteurs.

Comme la méthode Agile est devenue une mode, et qu’il existe tout un business autour, on qualifie tout et n’importe quoi d’Agile par ailleurs. Méfiez-vous donc, il ne suffit pas que le projet soit découpé en sprints pour que le projet soit réellement « agile ».

Par ailleurs, même si les tenants de la méthode ont une certaine tendance à dire qu’elle s’applique à tout merveilleusement, dans la pratique, deux phases sont peu gérées dans la méthode Agile : la phase de définition du projet en amont, et la phase de mise en production ensuite.

En amont, la définition du projet reste souvent un projet en cascade. On assiste souvent à la création d’une succession de documents : cadrage projet -> cahier des charges simplifié -> expressions de besoin -> user stories.

C’est en fait normal : des méthodes plus récentes (comme la méthode DAD Disciplined Agile Delivery) encapsulent Scrum Agile dans un système plus vaste dans lequel la gestion de la phase de définition du projet est mieux définie, ainsi que les processus optimisés pour gérer les MEP et les phases de « run » ensuite (la correction des bugs et l’amélioration continue de l’existant).

Fig. 8. Un schéma montrant le cycle de développement en méthode DAD : la phase de conception et de mise en service du produit font l’objet d’un process particulier, la phase de développement suit la méthode Scrum Agile a peu de choses près.
A noter : le rôle des experts internes ou externes comme les spécialistes SEO est prévu dans cette méthode.

SEO et méthode agile : bien maîtrisée, la méthode Agile permet de prévenir la plupart des ratés habituellement constatés dans les projets internet

Un projet web géré en mode Agile est une bonne opportunité pour un spécialiste SEO de s’assurer que le produit fini sera bien compatible SEO. Mais cela demande une implication de tous les instants :

• En amont, lors de la définition du projet et de la rédaction des users stories ;
• Pendant le développement, avec le suivi du backlog, des sprints, des revues de code et des recettes ;
• Et à la fin, avec les recettes en pré-production et en production.

Cela demande une très grande proactivité, de bonnes capacités de communication avec les équipes et de la pédagogie, et une grande force de conviction.

Mais cela demande aussi une bonne maîtrise technique et une bonne compréhension des process Agile. Conclusion : messieurs les spécialistes SEO, si vous ne voulez pas subir une gestion de projet en mode Agile, formez-vous à Scrum Agile !

 

Philippe Yonnet, fondateur de l’événement SEO Search Y (https://www.search-y.fr)