La technologie sous-jacente à SEOJuice (et pourquoi elle est ennuyeuse)

TL ; DR : La plupart des articles sur la « tech stack » répondent à la mauvaise question. L’enjeu utile derrière la pile technologique de SEOJuice n’est pas le logo affiché sur StackShare, mais la façon dont seojuice.com empêche le crawl, le scoring, la facturation, les suggestions de liens et les pages indexables de se saboter mutuellement.

La liste des outils est la partie la moins intéressante de la stack SEOJuice

seojuice.com n’a pas démarré comme une grande plateforme. Le projet vient du même problème que je voyais chez mindnow et sur vadimkravcenko.com : les équipes publiaient un contenu correct, puis laissaient des liens internes manquants, des métadonnées périmées, des pages orphelines et des correctifs lents végéter des mois dans le backlog. La technique derrière SEOJuice n’est donc pas optimisée pour les slides de conférence, mais pour un nettoyage récurrent qui ne devrait pas nécessiter un nouveau sprint SEO.

C’est pour cela qu’une simple liste d’outils paraît faible. StackShare donne des noms et une fiche rapide (la réponse publique actuelle). Très bien. Mais ces noms ne disent pas si un produit tient le coup face à des crawls lents, des requêtes bloquées, des caches vides, des données foireuses, des cas limites de facturation ou des pannes partielles.

J’ai conçu assez de systèmes clients chez mindnow pour savoir que l’architecture ne casse presque jamais sur le « happy path ». Elle casse à 2 h du matin — quand une file d’attente sature, qu’un crawler est bloqué ou qu’une « simple » mise à jour de contenu change l’URL canonique de 400 pages.

Les outils SEO sont complexes parce qu’ils se situent entre l’intention humaine, le HTML du site, les crawlers, les API tierces, les tâches planifiées et l’interface produit. Un marketeur clique sur un bouton et attend des recommandations utiles. Derrière ce clic, le système doit récupérer des pages, parser des liens, détecter les doublons, scorer les opportunités, stocker les preuves, respecter les limites et afficher la progression sans mentir.

Ce billet n’est donc pas un catalogue de fournisseurs. C’est une carte des modes de défaillance. La vraie stack SEOJuice, ce sont les choix qui rendent l’entretien SEO ennuyeux… et bon marché.

Version courte : ce qu’on attend réellement de la stack SEOJuice

Si vous vouliez la réponse directe, la voilà : la stack SEOJuice se comprend mieux par rôle que par marque. Les services peuvent changer, les responsabilités non.

Ce tableau est moins sexy qu’un mur de logos. Tant mieux. SEOJuice doit rester ennuyeux là où l’ennui est une vertu : récupérable, observable et facile à comprendre.

Lacune SERP : les résultats actuels s’arrêtent avant la vraie réponse

StackShare répond au « quoi », pas au « pourquoi »

StackShare est utile pour une recherche rapide. Il satisfait la requête littérale. Mais la personne qui tape seojuice tech stack veut souvent plus que des anecdotes de fournisseurs. Elle veut savoir si le produit tient grâce à un script bricolé ou à des choix d’ingénierie sains.

Ce qui manque, c’est l’adéquation. Pourquoi un outil SEO a-t-il besoin de tâches en arrière-plan ? Pourquoi séparer les pages publiques des écrans applicatifs ? Pourquoi stocker les timestamps de crawl ? Pourquoi les limites doivent-elles apparaître comme un comportement produit plutôt que comme des échecs aléatoires ? Une simple fiche de stack ne peut pas l’expliquer.

Stripe montre comment les systèmes matures gèrent les limites

Le blog engineering de Stripe ne parle pas d’outillage SEO, mais sa réflexion sur les rate limits s’applique parfaitement. Paul Tarjan écrit :

« Nos limites de requêtes sont constamment atteintes. Rien que ce mois-ci, elles ont rejeté des millions de requêtes. »

Cette phrase est importante parce qu’elle traite les limites comme un comportement normal en production, pas comme un patch d’urgence. Les logiciels gourmands en crawl doivent adopter le même état d’esprit. Un seul gros site ne doit pas ralentir tous les comptes. Un retry répétitif ne doit pas matraquer le serveur du client. Les limites tierces ne doivent pas apparaître dans l’UI sous forme d’erreurs mystères.

Vercel illustre la valeur de supprimer les frictions

Les articles de Vercel sont utiles pour une autre raison : la vitesse de livraison. Lee Robinson le résume ainsi :

« Votre meilleur atout peut être la rapidité avec laquelle vous livrez, écoutez les retours et itérez. »

Je suis d’accord, à une condition. La vitesse n’est utile que si le système reste assez simple pour revenir en arrière, observer et raisonner. Sinon, la rapidité devient juste un moyen plus élégant de créer des incidents.

Principe 1 : statique d’abord là où Google compte, en mode app là où l’utilisateur travaille

seojuice.com ne doit pas traiter toutes les surfaces de la même façon. Les pages publiques, billets de blog, docs et landing pages ont besoin d’un HTML rapide et de métadonnées stables. Les écrans authentifiés du produit exigent interactivité, filtres, états, données utilisateur et mémoire de workflow.

Ce sont deux jobs différents.

Les surfaces SEO publiques doivent produire un HTML crawlable au premier chargement, avec titres, descriptions, canonicals et liens internes prévisibles. C’est là que le HTML statique-first et le rendu applicatif prennent tout leur sens. Google n’a pas besoin de votre dashboard. Les utilisateurs, si. Confondre ces deux surfaces, c’est reconstruire tout le projet parce qu’une route utilisait le mauvais modèle de rendu.

Le dashboard peut se comporter comme une application : statut de projet, filtres, suggestions ignorées, état de facturation, avancement du crawl, actions interactives. Cette surface n’a pas besoin de ranquer sur « UI de scoring de page » (pas un mot-clé). Elle doit aider l’utilisateur à finir son travail sans attendre les crawlers.

Le domaine partagé n’est pas la partie intéressante. Ce qui compte, c’est de refuser d’imposer un seul modèle de rendu à toutes les routes. Les pages publiques doivent être indexables et stables. Les écrans privés doivent être utiles et stateful.

Principe 2 : crawlers et scoring ne doivent pas être sur le chemin de la requête

Le bouton doit enregistrer le projet, pas devenir une prise d’otage face à un WordPress poussif.

Cette phrase résume une bonne partie de la stack SEOJuice. Lorsqu’un utilisateur crée ou met à jour un projet, l’app doit enregistrer la requête, mettre le crawl en file d’attente et renvoyer un statut clair. Les crawlers récupèrent ensuite les pages sous limites. Les parseurs extraient titres, headings, canonicals, contenu, liens internes et détails de réponse. Le scoring tourne une fois assez de contenu disponible.

L’UI lit l’état courant. Elle ne doit pas faire semblant que tout est instantané.

C’est là que les files d’attente comptent. Le crawl est lent comparé aux actions web classiques. Certains sites répondent en 80 ms, d’autres en huit secondes. Certains bloquent les user-agents inconnus. D’autres redirigent cinq fois avant de servir une page, ou renvoient un HTML différent selon les headers. Si ce travail se fait pendant la requête — synchrone, bloquant, sur le clic — le produit devient aussi lent que le pire site crawlé.

Le traitement en arrière-plan rend aussi les retries plus sûrs. Un fetch raté peut être retenté avec un budget. Une URL bloquée peut être marquée. Un crawl peut se mettre en pause. Un job de scoring peut attendre le parsing au lieu de deviner.

« Il n’y a que deux choses vraiment dures en informatique : l’invalidation de cache et le choix des noms. »

La phrase de Phil Karlton reste vraie. Dans un logiciel SEO, un cache périmé n’est pas qu’un bug technique : il peut entraîner des liens suggérés depuis une page supprimée, ignorer une page publiée hier ou dire qu’un titre est correct après que le CMS l’a modifié.

La mauvaise architecture paraît rapide jusqu’à ce qu’elle mente

Les faux résultats instantanés sont dangereux. Si les recommandations s’affichent avant la fin du crawl, le produit semblera rapide cinq minutes, puis la confiance chutera. L’utilisateur verra des données périmées et doutera de tout le reste.

Je me suis trompé des années là-dessus (j’aimais trop les interfaces « instantanées »). Aujourd’hui, je préfère afficher une progression honnête plutôt qu’une certitude inventée. « Nous avons trouvé 180 pages et scoré 92 pour l’instant » vaut mieux qu’un tableau complet fondé sur des suppositions.

Principe 3 : les rate limits sont un comportement produit, pas une déco backend

Les rate limits sont souvent décrites comme de la prévention d’abus. Pour SEOJuice, elles définissent aussi l’équité, la fiabilité et la confiance client.

Un gros site ne doit pas ralentir tous les autres comptes. Les retries répétés ne doivent pas taper éternellement le serveur du client. Les pics API ne doivent pas se traduire par des échecs aléatoires dans l’UI. Les plafonds des formules tarifaires doivent ressembler à des promesses claires, pas à des pièges.

Les limiteurs façon Redis sont utiles, mais ils ne doivent pas devenir un SPOF. La deuxième leçon de Tarjan chez Stripe est celle qui m’importe le plus :

« Assurez-vous que si un bug survient dans le code de rate limiting (ou si Redis tombe), les requêtes ne soient pas impactées. »

C’est le bon réflexe. Si le limiteur tombe, l’activité normale doit dégrader proprement. Peut-être que le crawl ralentit, qu’une file se met en pause, que l’UI affiche un statut différé. Ce qui ne doit pas arriver, c’est une panne totale parce que la couche de protection est plus fragile que ce qu’elle protège.

Les limites doivent aussi être assez visibles pour que l’utilisateur comprenne. « Votre crawl est mis en file car ce site est déjà en cours d’analyse » vaut mieux qu’un spinner infini.

Principe 4 : les données SEO exigent un stockage ennuyeux et un état explicable

L’automatisation SEO perd la confiance si elle ne peut pas expliquer une recommandation.

SEOJuice a donc besoin d’un état durable pour les choses banales : comptes, projets, sites, URLs crawlées, pages parsées, opportunités de lien, statut des recommandations, suggestions ignorées, actions utilisateur, timestamps de crawl et indicateurs de fraîcheur. Rien de glamour, tout est essentiel.

Les bases de données « ennuyeuses » sont sous-estimées. Les recommandations SEO ont besoin de mémoire.

Si une page a changé hier, l’utilisateur doit savoir si la suggestion vient du crawl d’hier ou de celui du mois dernier. Si une recommandation a été rejetée, le système doit s’en souvenir. Si une URL a redirigé, le produit ne doit plus recommander l’ancien emplacement. Si une page a disparu, les recommandations liées doivent expirer.

C’est là que le naming devient vérité produit. Une « page », une « URL », un « canonical » ou une « recommandation » semblent évidents… jusqu’aux redirections, doublons et templates CMS. Une mauvaise nomenclature crée de mauvais modèles mentaux, donc des tickets support.

La couche de stockage n’a pas besoin d’être maligne — elle doit être explicable. Quand SEOJuice suggère un lien interne, le produit doit pouvoir répondre : de quelle page vers quelle page, basé sur quel crawl, avec quel ancrage, et dans quel état ?

Principe 5 : la stack doit sécuriser des releases petites et fréquentes

La leçon de Vercel sur la vitesse d’expédition est utile, mais SEOJuice n’a pas besoin d’un théâtre façon plateforme. Il lui faut des boucles de feedback courtes.

Les petites releases sont plus simples à relire. Des logs clairs facilitent la chasse aux jobs cassés. Les rollbacks réduisent la peur. Les feature flags aident quand le risque est élevé. Une revue manuelle reste pertinente près de la logique de recommandation, surtout si une modification de scoring peut impacter beaucoup d’utilisateurs d’un coup.

Parenthèse : j’ai longtemps surévalué l’architecture « maligne ». Ça semble responsable, mais ça ralentit souvent le prochain correctif.

Le pipeline de livraison doit rendre bon marché les correctifs de contenu, UX, billing ou scoring. Pas téméraire, mais assez petit pour être compris et assez réversible pour dormir tranquille.

Même chose pour l’automatisation du maillage interne. Un moteur de recommandation s’améliore via les retours : les utilisateurs ignorent certaines suggestions, en acceptent d’autres, révèlent des cas limites invisibles dans les jeux de test. La stack doit permettre de transformer ces leçons en changements produit rapidement.

Ce que nous choisissons sciemment de ne pas optimiser

Pour être franc, certaines choses ne valent pas l’effort.

La stack SEOJuice ne doit pas impressionner les ingénieurs au détriment des utilisateurs. Elle gagne la confiance quand le produit est prévisible : enregistrer le projet, crawler en toute sécurité, montrer la progression, expliquer les recommandations, mémoriser les décisions et se remettre des pannes.

Ça paraît banal, parce que ça l’est. Et c’est voulu.

Alors, c’est quoi vraiment la stack SEOJuice ?

La stack SEOJuice est un ensemble de rôles : surfaces frontend pour pages publiques et écrans applicatifs, couche backend pour comptes et recommandations, stockage durable pour l’état SEO, files pour crawl et scoring, cache et rate limits pour la vitesse et la protection, monitoring pour jobs et retries en échec, et un chemin de déploiement qui garde les releases petites.

Si les noms de services changent, cette description doit rester vraie. Les rôles sont plus stables que les outils.

Les pages publiques doivent être crawlables et rapides. Les écrans applicatifs doivent être réactifs et stateful. Les crawlers ont besoin d’isolement. Le scoring exige des preuves stockées. La facturation requiert un état de compte durable. Les limites veulent des fallback sûrs. Les logs doivent rendre les pannes visibles avant que les utilisateurs les signalent.

Cet article n’est pas un document d’architecture interne et ne prétend pas l’être. La transparence utile, c’est le modèle opératoire : statique-first là où Google compte, avec files d’attente là où le crawl est lent, fail-safe là où les limites protègent le produit, et un stockage « ennuyeux » là où les décisions de lien doivent être expliquées.

FAQ

Qu’est-ce que la stack SEOJuice ?

La stack SEOJuice mêle livraison de pages publiques, infrastructure applicative, stockage persistant, jobs en arrière-plan, cache, rate limits et monitoring. Les noms exacts pèsent moins que les responsabilités : pages crawlables, écrans réactifs, état SEO durable, crawl sécurisé, recommandations explicables et pannes observables.

Pourquoi ne pas publier tous les noms de services internes ?

Une liste de fournisseurs devient vite obsolète et offre une transparence trompeuse. Connaître un logo ne dit rien sur la façon dont le système gère crawls, pannes, retries, limites et état des recommandations. La réponse utile est architecturale, pas décorative.

SEOJuice est-il conçu pour Googlebot ou pour les utilisateurs ?

Pour les deux, mais pas sur la même surface. Les pages publiques sont conçues pour être crawlables par défaut. Le dashboard est pensé pour le workflow utilisateur : projets, filtres, statut de crawl, recommandations, actions.

Pourquoi un outil SEO a-t-il besoin de files d’attente ?

Le crawl, le parsing et le scoring sont lents par rapport aux actions habituelles de l’utilisateur. Les files maintiennent l’app réactive, rendent les retries plus sûrs et évitent qu’un site lent ne bloque tout le monde.

Envie de sortir le travail SEO ennuyeux de votre backlog ?

Si votre équipe repousse sans cesse maillage interne, métadonnées périmées, pages orphelines et nettoyage de contenu, SEOJuice est conçu exactement pour combler ce vide. La stack est volontairement ennuyeuse — pour que la maintenance se fasse sans devenir un nouveau projet d’ingénierie.