Daspeed : de 2023 à 2026, passer des audits SEO aux campagnes rejouables

1. Daspeed, un produit Dawap dédié à la qualité technique des sites

Faire travailler ensemble collecte, diagnostic et historique

Daspeed s’adresse au suivi technique de sites qui possèdent plusieurs pages et dont les signaux changent avec les contenus, les gabarits, les scripts et les mises en production. Une mesure isolée décrit un instant ; le produit doit lui donner un contexte pour devenir utile.

Le périmètre ne se limite pas à la vitesse. Performance, accessibilité, bonnes pratiques, SEO, indexabilité, profondeur de crawl, liens internes, données structurées et titres de résultats répondent à des questions différentes. L’application doit les séparer sans obliger l’utilisateur à apprendre un workflow différent pour chaque outil.

Le produit doit également composer avec des contraintes d’exploitation : pages découvertes en volume variable, appels à des services externes, quotas de clés, traitements longs et consolidation différée. L’interface ne peut pas attendre qu’une requête web réalise tout le travail.

Enfin, Daspeed est lui-même un terrain d’évolution. La première génération fonctionne autour d’audits et de classements ; la seconde formalise les concepts qui manquaient pour industrialiser les outils. Cette continuité permet de raconter les choix réellement faits plutôt qu’une plateforme idéale apparue d’un seul bloc.

2. Deux générations, une même question de pilotage

Centraliser d’abord, puis rendre l’exécution traçable et rejouable

De juin 2023 à janvier 2024, le premier produit construit les comptes, espaces de travail, sites, pages, analyses et vues publiques. Les collectes PageSpeed et GTmetrix sont séparées par mobile et desktop ; les contrôles SEO complètent la lecture avec statuts, titres, métadonnées, robots, sitemaps et textes alternatifs.

Cette génération distribue déjà le travail avec Symfony Messenger. Des files distinctes prennent en charge l’intégration des sitemaps, l’initialisation d’un site, l’analyse des pages et la génération des journaux. Les échecs rejoignent un transport dédié et les tentatives sont bornées.

Du 14 février au 5 mars 2026, la refondation installe une convention commune à tous les outils. Le domaine porte les cas d’usage, les adaptateurs techniques gèrent API, crawler, persistance et messages, tandis que les écrans présentent démarrage, progression, résultat et vue d’ensemble.

La génération 2026 concentre son premier jalon sur sept outils disposant du cycle de campagne complet. D’autres fonctions sont préparées progressivement : elles rejoindront ce périmètre lorsqu’elles suivront le même niveau d’orchestration, de consolidation et de restitution.

3. Commencer par donner une identité au site et à ses pages

Le 19 juin 2023, la première fondation Daspeed apparaît

Un audit technique porte toujours sur un périmètre. Daspeed représente donc d’abord le compte, l’espace de travail, le projet, le site et les pages qui lui appartiennent. Cette hiérarchie évite que les résultats soient stockés comme des mesures sans propriétaire ni contexte.

La page devient l’unité sur laquelle les services externes et les contrôles internes travaillent. Son adresse, son site et ses analyses peuvent évoluer séparément, tandis que les vues du site regroupent les résultats utiles au pilotage.

Le produit comprend aussi une partie publique. Des classements par site, catégorie et agence permettent de présenter les analyses avec plusieurs niveaux de lecture. Les pages publiques séparent notamment les résultats globaux, mobiles et desktop.

Ce premier choix donne au produit une structure durable : un score n’existe jamais seul. Il appartient à une page, elle-même rattachée à un site et à un espace où des utilisateurs peuvent travailler.

4. Réunir les contrôles qui décrivent réellement une page

Performance, contenu technique et accessibilité dans des vues distinctes

La première génération construit deux familles d’audits. Website Score Audit restitue les catégories de performance, accessibilité, bonnes pratiques et SEO. Website SEO Audit se concentre sur les éléments de page : statut HTTP, titres, métadonnées, images, robots et sitemaps.

Cette séparation évite d’aplatir tous les signaux dans une seule note. Une page peut être rapide et présenter une canonique incorrecte ; une autre peut être techniquement indexable mais pénalisée par ses ressources mobiles. Les écrans doivent laisser voir ces différences.

Les classements offrent une autre vue du même catalogue. Ils peuvent comparer des sites et exposer les pages qui composent chaque résultat, sans remplacer l’espace de travail où les analyses sont lancées et relues.

Au 24 janvier 2024, cette première génération réunit les modèles métier, les parcours web, les services de consultation, les messages et les vues nécessaires pour faire vivre ces audits dans une application Symfony 6.

5. Séparer PageSpeed, GTmetrix et les contrôles de contenu

Chaque source conserve son rôle et son profil d’exécution

PageSpeed est interrogé séparément pour mobile et desktop. Les réponses possèdent leurs propres objets de lecture et leurs propres actions de mise à jour. Le produit peut ainsi comparer des profils sans mélanger deux conditions de mesure dans un champ unique.

GTmetrix suit la même distinction dans les messages d’analyse. Daspeed orchestre les demandes desktop et mobile, puis les rattache à l’analyse de la page concernée. La plateforme ne présente pas GTmetrix comme une source interchangeable avec PageSpeed.

Les statuts HTTP et les métadonnées passent par d’autres traitements. Une page indisponible, un titre absent ou une description incohérente n’ont pas besoin d’attendre le même service externe qu’un score de performance pour devenir visibles.

Les journaux quotidiens conservent ensuite des agrégats, notamment sur les niveaux de performance des pages. Cette première historisation prépare déjà la question qui deviendra centrale en 2026 : comment suivre une évolution sans perdre la provenance du calcul ?

6. Distribuer les analyses sans bloquer l’interface

Des files distinctes pour la découverte, le traitement et les journaux

L’intégration d’un sitemap peut découvrir de nombreuses pages. L’analyse de chacune peut ensuite déclencher plusieurs appels. Daspeed place ces responsabilités dans des messages asynchrones afin que la requête de l’utilisateur ne reste pas ouverte pendant toute la campagne.

La première génération distingue les files d’initialisation du site, d’intégration du sitemap, de démarrage d’analyse de page, de collectes PageSpeed et de génération de journaux. Cette séparation rend les responsabilités plus lisibles et permet aux workers de progresser indépendamment.

Le transport générique prévoit trois tentatives espacées de trente secondes. Les messages qui échouent rejoignent une file Doctrine dédiée, ce qui évite qu’une erreur disparaisse après la dernière tentative.

Cette architecture résout le blocage HTTP, mais elle ne répond pas encore complètement à la visibilité d’ensemble : combien de pages appartiennent à la campagne, lesquelles restent en attente et à quel moment l’agrégat devient-il opposable ?

7. Offrir plusieurs niveaux de lecture sans masquer le détail

Vue site, liste de pages et analyse individuelle

Les écrans Website Score Audit proposent une vue d’ensemble, une liste de pages, puis des onglets dédiés à la performance, l’accessibilité, aux bonnes pratiques et au SEO. L’utilisateur peut partir d’un signal global et descendre jusqu’à la page qui l’explique.

Website SEO Audit complète ce parcours avec ses propres vues : titres, métadonnées, textes alternatifs, robots, sitemaps et suivi. La distinction reflète deux usages : lire des catégories de score et contrôler les fondations éditoriales ou d’indexation.

Les classements publics reprennent également plusieurs angles : résultat global, mobile, desktop et détail par page. Ils transforment une partie des données du produit en découverte publique sans ouvrir les fonctions de travail réservées à l’application.

Cette restitution pose une base produit solide. Elle montre aussi pourquoi la suite ne peut pas se limiter à ajouter des dashboards : la fiabilité dépend d’abord de la manière dont chaque résultat est produit et consolidé.

8. Quand la file de messages ne suffit plus à raconter une campagne

Relier l’intention de départ, chaque page traitée et la fin du run

Un message sait demander une action, mais il ne représente pas à lui seul la campagne complète. Si cent pages sont découvertes, le produit doit pouvoir distinguer une exécution en cours d’une exécution partielle, annulée ou terminée.

La même difficulté apparaît lors d’une reprise. Rejouer un message ne doit pas créer deux résultats concurrents, compter deux fois une page ou finaliser deux fois le même agrégat. L’idempotence devient une propriété métier, pas seulement une précaution d’infrastructure.

Enfin, la dernière mesure et l’historique ne répondent pas à la même question. Écraser la valeur courante conserve la simplicité mais détruit la trajectoire ; conserver uniquement tous les résultats rend coûteuse la lecture du présent.

La refondation de 2026 part de ces tensions. Elle ne cherche pas d’abord à ajouter une source d’audit supplémentaire ; elle transforme le cycle d’exécution en modèle explicite.

9. Repartir sur Symfony 8 autour du domaine de campagne

Stabiliser les contrats avant de multiplier les outils

La nouvelle génération démarre le 14 février 2026. Elle adopte PHP 8.4 au minimum, Symfony 8, Doctrine 3 et les composants Messenger, Lock, HTTP Client, Dom Crawler et UX nécessaires au produit.

L’architecture sépare le domaine des implémentations Symfony. Les cas d’usage dépendent de contrats pour lire, écrire, appeler PageSpeed, explorer un site ou publier un message. L’infrastructure fournit ensuite les adaptateurs Doctrine, HTTP et Messenger.

Une convention commune encadre les nouveaux cas d’usage : requête, réponse, presenter, interface et service d’exécution. Cette régularité rend les frontières identifiables lorsqu’un outil ajoute une validation ou change son mode de persistance.

Le projet conserve une interface web complète, mais le workflow n’est pas caché derrière elle. Les routes distinguent le démarrage, la progression, le résultat de campagne, le snapshot et la vue d’ensemble par site.

10. Faire passer chaque outil par Explore, Process et Finalize

Trois étapes pour borner le début, le détail et la consolidation

Explore démarre après la création du run et de la campagne. Il applique la source de découverte choisie, crée une unité d’analyse par page et place chaque traitement en attente. Le périmètre devient une donnée du produit avant le premier résultat.

Process prend ensuite une page, exécute le contrôle propre à l’outil et écrit un résultat relié à l’unité d’analyse ainsi qu’à la campagne. Cette double relation permet de suivre le travail générique et le détail fonctionnel sans les confondre.

Finalize intervient lorsque la file est prête à être consolidée. Il calcule les indicateurs de campagne, met à jour les états de page et de site, puis inscrit les points journaliers correspondants.

Ce trajet est partagé par les sept outils du premier jalon. L’utilisateur retrouve donc le même langage de progression même lorsque la donnée analysée passe des Core Web Vitals aux titres SERP ou à la profondeur de crawl.

11. Rendre la découverte des pages explicite

Savoir ce qui entre dans la campagne avant d’interpréter ses résultats

Une campagne n’est comparable à une autre que si son périmètre est connu. Explore conserve la source de découverte et matérialise chaque page sous forme d’unité d’analyse. Une page absente du run ne peut pas être confondue avec une page ayant obtenu un résultat neutre.

Le crawler et les services qui retrouvent les pages sont placés derrière des contrats. Un outil peut ainsi partir des pages déjà connues du site ou d’un parcours spécifique sans modifier la manière dont Process et Finalize raisonnent.

Les unités commencent dans un état de file. La progression peut compter ce qui attend, ce qui travaille et ce qui a abouti. L’interface dispose alors d’une information plus utile qu’un simple écran de chargement.

Ce choix protège aussi les reprises. Le run porte l’identité de la campagne et ses analyses ; un message rejoué retrouve le même contexte au lieu de reconstruire silencieusement un second périmètre.

12. Attacher chaque résultat à son exécution

Une page traitée reste reliée à la campagne qui l’a mesurée

Process écrit dans une table de résultats propre à l’outil. Le lien vers la campagne est obligatoire : une donnée Core Web Vitals ou SEO Change Radar ne peut pas devenir un résultat orphelin dont la date et le périmètre seraient impossibles à retrouver.

L’unité générique d’analyse conserve de son côté la progression du run. Cette séparation permet d’exposer un suivi commun à tous les outils sans réduire leurs résultats à un schéma identique.

Les appels externes restent encapsulés. Core Web Vitals Watch utilise un client PageSpeed, des pools de clés et une sonde dédiée. SEO Change Radar s’appuie sur un crawler et un client HTTP adaptés aux changements qu’il doit détecter.

En cas d’indisponibilité temporaire d’une clé, le traitement peut rester en attente plutôt que produire un faux échec fonctionnel. La file devient ainsi un outil de régulation, pas seulement un moyen de déporter le calcul.

13. Conserver cinq niveaux sans écraser la provenance

Résultat de page, état courant et historique aux deux échelles

Le résultat de page décrit ce que la campagne a produit. Il reste attaché à son exécution et sert à comprendre un incident, un score ou une différence entre deux runs.

L’état courant de page retient la dernière lecture exploitable pour l’interface quotidienne. Son historique journalier ajoute au plus un point par jour et par page, en mettant à jour ce point lorsqu’une nouvelle campagne du même jour le remplace.

Le même principe existe au niveau du site. Un état agrégé facilite la vue d’ensemble ; un enregistrement journalier permet de suivre l’évolution sans recalculer toutes les campagnes lors de chaque consultation.

La campagne constitue le cinquième niveau : elle porte ses propres indicateurs consolidés. Le produit peut ainsi répondre séparément à « que s’est-il passé dans ce run ? », « où en est cette page ? » et « comment ce site évolue-t-il ? ».

14. Core Web Vitals Watch : orchestrer PageSpeed sans perdre le contexte

Clés, traitement par page, snapshot et vue d’ensemble

Core Web Vitals Watch applique le cycle complet avec ses messages Explore, Process et Finalize, ses écrans de démarrage, progression, campagne, snapshot et vue d’ensemble, ainsi que ses services de lecture et d’écriture.

Le service PageSpeed distingue des pools de clés publiques et administrateur. Un verrou protège leur utilisation concurrente, tandis que le statut de traitement permet de remettre une page en file lorsqu’aucune clé n’est momentanément disponible.

Les résultats alimentent les états de page et de site, puis leurs historiques. L’overview peut présenter la situation actuelle et descendre vers le détail d’une page sans recalculer le run complet.

Cette capacité complète l’accompagnement Performance et Core Web Vitals : Daspeed fournit ici le produit de campagne et de suivi, tandis que la prestation traite l’analyse et les corrections sur le site concerné.

15. SEO Change Radar : distinguer changement observé et état opposable

Crawler, résultats par page, journées et export CSV

SEO Change Radar utilise le même squelette de campagne pour une autre question : qu’est-ce qui a changé dans les pages observées ? Ses contrats couvrent exploration, traitement, finalisation, crawler, client HTTP, compteur de run et enregistrement d’usage.

L’interface expose la progression, le résultat de campagne, le snapshot, la vue par jour, les pages regroupées par statut et le détail d’un état de page. Un export CSV permet de sortir le snapshot sans confondre cette extraction avec la base historique.

Les entités séparent campagne, résultat de page, état courant de page, historique journalier, état de site et historique de site. Le modèle commun devient tangible sur un outil où la comparaison temporelle constitue le cœur de la valeur.

La finalisation et les compteurs sont protégés pour éviter qu’un double passage transforme une même page en deux changements. Cette propriété rend le rejeu compatible avec la confiance attendue d’un radar.

16. Sept outils disposent du cycle complet de campagne

Un même parcours, des résultats métier différents

Le jalon du 5 mars 2026 couvre Core Web Vitals Watch, Crawl Depth & Orphan, Indexability Monitor, Internal Link Equity Map, Schema.org Validator, SEO Change Radar et SERP Title Guard. Chacun possède les parcours de démarrage, progression et résultat correspondant au workflow commun.

Les outils gardent pourtant leur propre modèle. Une carte de liens internes manipule des pages sources, cibles et signaux d’équité ; un validateur Schema.org examine des données structurées ; un contrôle d’indexabilité qualifie des décisions d’accès aux moteurs.

Cette combinaison évite de créer sept petites applications isolées. Les campagnes partagent l’identité du run, le suivi et les conventions de restitution, tandis que le domaine de chaque outil conserve ses règles et ses agrégats.

Crawl Budget Optimizer possède déjà un point d’entrée et un écran de démarrage. Son cycle de campagne n’atteint toutefois pas encore le même niveau que les sept outils livrés ; il constitue donc une étape suivante du produit.

17. Traiter les quotas et la concurrence comme des états du produit

Attendre une ressource sans transformer l’attente en erreur métier

Les services externes n’offrent pas une capacité infinie. PageSpeed impose l’usage de clés et des limites qui peuvent rendre une ressource indisponible au moment où un worker prend une page.

Daspeed distingue les pools selon le contexte et applique un verrou lors de la sélection. Deux traitements ne peuvent pas s’approprier la même ressource comme si elle était libre, ce qui réduit les collisions au niveau du client externe.

Lorsque la clé manque, le statut `API_KEY_BUSY` conserve le travail dans la trajectoire de traitement. L’attente ne devient ni un résultat vide ni un échec définitif. La page peut reprendre lorsqu’une capacité est disponible.

Finalize possède la même exigence face à la concurrence. Une double exécution ne doit pas doubler les indicateurs ni créer plusieurs points journaliers. Les verrous et upserts protègent la signification des agrégats.

18. Montrer où en est la campagne avant d’afficher son verdict

Démarrage, progression, résultat, snapshot et overview

Le parcours commence par le choix du site et de la source de découverte. L’utilisateur déclenche ensuite la campagne ; la requête web ne réalise pas tous les contrôles, elle crée le contexte puis confie le travail aux messages.

L’écran de progression est accessible par campagne ou par run. Une vue live et une carte de progression permettent de suivre l’avancement sans interpréter une campagne incomplète comme son résultat final.

La page de campagne restitue l’exécution terminée. Le snapshot répond à la lecture courante, tandis que l’overview par site rassemble les tendances et donne accès au détail d’une page lorsque l’outil le prévoit.

Cette séquence reprend la réalité du traitement plutôt que de la cacher. Elle aide à comprendre pourquoi une campagne importante peut continuer après le clic initial et à quel moment ses agrégats deviennent utilisables.

19. Préparer un environnement adapté aux campagnes longues

PHP, Nginx, MySQL, Redis, RabbitMQ et Playwright séparés

La composition de production distingue le serveur Nginx, l’application PHP, MySQL, Redis, RabbitMQ et un service Playwright. Chaque responsabilité peut évoluer ou redémarrer sans être intégrée dans un unique conteneur opaque.

RabbitMQ transporte les campagnes asynchrones. Redis fournit le stockage rapide et les mécanismes nécessaires à certaines coordinations. MySQL conserve les comptes, sites, campagnes, résultats, états et historiques.

Playwright donne au crawler un navigateur séparé de PHP pour les pages qui nécessitent un rendu. La production dispose d’une image dédiée au lieu d’installer un navigateur complet dans le processus applicatif.

La pipeline construit et publie des images PHP, Nginx et Playwright pour les branches de travail et de production. Au 5 mars 2026, les commandes de tests applicatifs y sont encore désactivées : les activer avant la promotion des images devient la prochaine amélioration de la chaîne de livraison.

20. Ancrer les garde-fous dans le modèle et dans les tests

Idempotence, unicité journalière et doubles de services externes

Le standard de campagne exige que le résultat de page possède sa campagne, que Finalize résiste au double passage et que les historiques limitent chaque périmètre à un point journalier. Ces règles empêchent les anomalies les plus dangereuses pour la lecture du produit.

Le projet contient des tests applicatifs et d’intégration sur les parcours publics, les espaces de travail et le client PageSpeed. Des doubles de crawler et d’horloge permettent de vérifier certains flux sans dépendre d’un site externe ou de l’heure réelle.

Le client PageSpeed possède aussi son test d’intégration et ses objets de restitution. Le code distingue les scores des données brutes renvoyées par le service, ce qui limite la propagation du format externe dans les vues métier.

Ces tests sécurisent des parcours précis, sans valoir pour autant couverture exhaustive du produit. Leur exécution automatique dans la pipeline reste une étape à activer pour rapprocher construction des images et validation applicative.

21. Les arbitrages qui donnent sa forme à Daspeed

Privilégier la traçabilité avant la multiplication des tableaux de bord

Premier arbitrage : conserver les deux générations dans une seule histoire de produit. La version 2023 établit les audits et classements ; la version 2026 ne doit pas s’attribuer rétroactivement toutes ses fonctions, ni effacer les limites qui ont motivé sa refondation.

Deuxième arbitrage : séparer résultat, état et historique. Une table universelle aurait réduit le nombre de modèles, mais elle aurait mélangé preuve d’exécution, lecture actuelle et tendance quotidienne.

Troisième arbitrage : imposer Explore, Process et Finalize aux outils industrialisés. Cette régularité ajoute une discipline au démarrage, mais elle rend la progression, le rejeu et la consolidation comparables.

Quatrième arbitrage : ne compter comme outils complets que les sept familles disposant de tout le cycle. Un point d’entrée ou un écran de démarrage ne suffit pas ; il faut aussi le traitement, la consolidation et la restitution de la campagne.

22. Ce que la refondation change concrètement

Une plateforme capable d’expliquer ses résultats et son avancement

Le premier gain est la provenance. Chaque résultat de page reste rattaché à une campagne et à une unité de run. Une anomalie peut être relue dans le contexte de l’exécution qui l’a produite.

Le deuxième gain est la visibilité de progression. La campagne connaît les pages découvertes avant leur traitement et peut distinguer attente, exécution, résultat et consolidation. Une vue partielle n’est plus confondue avec le verdict final.

Le troisième gain est la continuité temporelle. L’état courant sert l’usage quotidien, tandis que les enregistrements journaliers conservent l’évolution de la page et du site sans recalculer toutes les campagnes.

Le quatrième gain est l’extension. Un nouvel outil peut reprendre le workflow, les conventions de messages, les écrans de progression et les règles de finalisation tout en gardant son propre domaine de résultats.

23. Scénario : une campagne Core Web Vitals attend une clé puis reprend

Voir comment le workflow évite un faux résultat et une double consolidation

Un utilisateur démarre Core Web Vitals Watch sur un site. Explore crée la campagne, découvre les pages et place une analyse en file pour chacune. La progression peut immédiatement annoncer le périmètre même si aucun appel PageSpeed n’est encore terminé.

Un worker prend une page alors que toutes les clés autorisées sont occupées. Au lieu d’écrire un score vide, il conserve l’analyse dans un état d’attente lié à la disponibilité de l’API. Le message pourra reprendre sans recréer la campagne.

Quand une clé devient disponible, Process exécute la sonde et écrit le résultat avec ses liens vers la page, l’analyse et la campagne. Les autres pages avancent indépendamment selon leurs propres ressources.

Finalize agrège une seule fois la campagne puis met à jour le snapshot de page, le point journalier, l’état de site et son historique. L’outil peut alors présenter le résultat du run et la situation actuelle sans les confondre.

24. Une trajectoire définie par les invariants du produit

Étendre les outils sans affaiblir le workflow commun

Le prochain enjeu n’est pas simplement d’augmenter le nombre de contrôles. Chaque nouvelle famille doit atteindre le même niveau : périmètre identifiable, résultat rattaché à la campagne, finalisation idempotente, états actuels et historiques lorsque leur usage le justifie.

Crawl Budget Optimizer illustre cette frontière. Son point d’entrée montre la direction, mais il rejoindra le périmètre livré lorsque son cycle possédera les mêmes étapes de traitement, de consolidation et de restitution que les sept outils complets.

Grafana ne faisait pas partie du périmètre livré pour Daspeed.io. La page intégrateur Grafana API prend le relais lorsqu’il faut gouverner dashboards, datasources, alertes et provisioning sans confondre cette expertise adjacente avec une livraison de ce cas.

La deuxième priorité concerne la chaîne de validation. Les tests existants doivent devenir une étape effective de la pipeline avant la promotion des images, afin que les garde-fous déjà écrits participent systématiquement à chaque livraison.

Pour une équipe qui veut construire un produit comparable, Dawap relie cette expérience au développement d’application métier et aux intégrations API SEO et Analytics : modéliser le cycle de décision avant de multiplier les données.