La façon de fabriquer des sites web a changé considérablement : plateformes headless, frameworks JS, low code, cloud... Dans le même temps, d'autres technologies deviennent obsolètes (vous pouvez laisser tomber l'AMP, ou l'App Indexing). Mais ces changements s'accompagnent de nouveaux challenges techniques pour le SEO, que vous devez prendre en compte avant de choisir la dernière technique à la mode.... Présenté par Philippe YONNET, CEO de Neper.

1. Les Nouvelles Architectures de
sites web et le SEO
Philippe YONNET
CEO Neper

2. Les outils et méthodes pour bâtir un site web
évoluent vite
Les sites mobiles en m. => le responsive
design a gagné
Les pages AMP : vous oubliez, cela n’a plus
d’avenir
Les plateformes / CMS hébergées sur des
serveurs dédiés => en voie d’abandon
rapide
A l’inverse, d’autres approches fleurissent :
SaaS, LoCode/Nocode, Headless, Cloud,
Serverless…
Et certaines sont déjà obsolètes

4. Architectures logicielles pour faire un site web ?
Concrètement, une architecture logicielle décrit comment un service est découpé en
composants, et comment ces composants interagissent entre eux.
Depuis l’invention du World Wide Web au début des années 90, une architecture
était dominante
C’est quoi une architecture logicielle ?

5. Mais depuis quelques années…
Et les développeurs ont
pu déployer une plus
grande créativité
Pour le pire et le meilleur
Côté SEO : souvent pour le
pire
… la technique a fait quelques progrès !

7. Euh… un site web c’est un site web non ?
Une petite sélection :
Utiliser un service SaaS
Les CMS headless
Les SPA
Les PWA
Les frameworks JS
Web Assembly
Les sites serverless
Et pour chaque techno, on va dire si c’est ok pour le SEO ou non
Il y’a maintenant des tas de façons de faire un site web

8. Bâtir son site web à partir d’un service SaaS
Une architecture de plus en plus fréquente

9. Pourquoi ces solutions sont populaires
Solutions presque « clés en main »
On peut (presque) se passer d’équipes
techniques pour fabriquer un site web
avec ces outils
Pas de maintenance
Scalabilité maximum
Coût (apparent) faible
Des coûts cachés à prendre en compte

10. SaaS : côté SEO cela donne quoi
On progresse, mais c’est pas top…
Aucune solution n’est nativement 100% compatible
Sauf si vous basculez en mode headless
Il y’a toujours un peu de travail d’optimisation à faire
Parfois beaucoup
Cela empire si vous cherchez à obtenir de ces outils
des choses pour lesquelles ils n’ont pas été conçus
Attention à l’impact des « développements
spécifiques »
A déconseiller si le SEO est stratégique pour vous
75% à
100%
Compatibilité SEO

11. Et le Nocode ? De quoi parle t’on ?
Les outils No-Code sont des plateformes
applicatives mises à disposition en ligne
qui permettent aux utilisateurs de créer
des programmes en glissant et déposant
les composants visuels qu'ils souhaitent
inclure dans leur application, sans avoir
recours à une seule ligne de code.
Ces outils fonctionnent comme des
services en mode SaaS
Ces plateformes génèrent du code, sans
que l’utilisateur ait besoin de savoir coder

12. Nocode ou Lowcode ?
Low-code : des outils qui permettent
d’augmenter la productivité de
développeurs
On code encore, mais très peu
On ne réinvente plus la roue
La promesse du no-code est plus
radicale :
Un non développeur peut fabriquer une
application ou un site web
Plus de code du tout
On verra que la promesse n’est pas
complètement tenue à ce jour
12
Source : Tiger Sheet - https://tigersheet.com/blog/category/lcnc/

13. Un concept à la mode
… qui cache un marché en rapide expansion
L’intérêt pour le nocode a été dopé par le confinement !
13

14. Quelques exemples d’outils no code
14

15. Wordpress est il un outil nocode ?
Oui, mais ça dépend !
S’il est hébergé chez un hébergeur spécialisé (Kinsta par exemple)
S’il est utilisé avec un framework permettant de monter des pages sans coder (Divi
etc…)
15

16. Nocode peut-être, mais pas no SEO
Ces outils n’optimisent pas vos sites ! L’optimisation SEO reste à faire
Si vous ne savez pas optimiser un site, le
CMS nocode ne vous aidera pas
D’une manière générale, sans
connaissances techniques en
HTML/CSS/JS et sur le fonctionnement
d’un site web, le CMS nocode ne saura
pas faire tout seul un site parfaitement
optimisé
16

17. Attention à ne pas dépendre de l’outil
Ces outils sont des outils SaaS, ils en ont les inconvénients
Si l’outil est down, votre site aussi
Les SLA servent plus à définir les limites
de responsabilité du service que de
protéger votre business
Si l’outil disparait… votre site aussi
Vu la concurrence actuelle, il va y avoir
des faillites et des fusions, le risque est
grand de devoir
Pouvez-vous facilement migrer de
votre outil actuel vers un autre outil
C’est pas gagné ! En général, rien n’est
prévu. Et vous risquez d’avoir besoin
d’un développeur pour migrer les
données

18. Le problème du « Shadow IT »
Si n’importe qui peut faire du nocode, il ne faut pas faire n’importe quoi
Les développements nocode ou lowcode
doivent rester dans le périmètre du DSI
Sinon cela développe le « shadow IT », c’est-à-
dire une infrastructure technique qui échappe à
la connaissance et à la surveillance du
département IT
Problèmes de sécurité et de confidentialité
Problèmes de maintenance
Problèmes d’évolution…
Etc…
18

19. Nocode et RGPD
Attention, la plupart des outils nocode sont hébergés aux USA
Si vous récoltez des données personnelles,
c’est un souci
Les solutions :
Passer par un outil nocode open source pour
pouvoir l’héberger vous même
Ça existe, mais ils sont loin d’être parfaits
Et du coup, autant héberger vous-même un
wordpress
19

20. NoCode et SEO
Oui, on peut utiliser des CMS NoCode et
avoir des bons résultats en SEO
Mais cela demande des efforts et de la
technicité en SEO
Tous les CMS ne sont pas parfaits d’un point
de vue SEO
Avec le NoCode on peut se passer de
devs, mais il faut des connaissances
techniques, et des connaissances en SEO
Le NoCode présente encore des limites
qui rendent son domaine d’application
limité à des usages précis
Et la dépendance au NoCode peut-être
problématique
75% à
100%
Compatibilité SEO

21. Les CMS headless
Si on veut faciliter la
génération de code pour
différents usages (mobile, IOT,
apps…)
Si on veut « assembler » des
données venant de différentes
API pour générer ses pages
Les CMS habituels sont lourds
et inadaptés
Les CMS headless fournissent
une solution radicale

22. Monolitique, couplé, découplé, headless ?
C’est quoi la différence ?

23. Quelques exemples de CMS headless
Les CMS purement « headless »
Strapi https://strapi.io/
Cockpit https://getcockpit.com/
Directus https://directus.io/
Les CMS découplés et semi découplés
Drupal (si si) :
https://www.drupal.org/about/9
Sitefinity :
https://www.progress.com/sitefinity-cms
Plateformes SaaS headless
Core DNA https://www.coredna.com/
Contentful https://www.contentful.com/
Kontent (ex Kentico) https://kontent.ai/
Et leur impact sur le SEO

24. Ok, mais les CMS headless, cela vaut quoi pour le
SEO ?
En théorie, tout le code « front », celui vu par les bots
des moteurs de recherche et interprété par les
navigateurs, peut-être écrit librement
Rien n’empêche d’avoir du code 100% SEO compliant
Mais le risque d’avoir un site mal fichu d’un point de vue
SEO est très important
C’est atténué si on utilise un CMS découplé car au moins
toutes les fonctionnalités SEO sont déjà codées
Gestion des balises title, meta robots, canonical…
Gestion des urls, des redirections…
Etc.

25. Les sites « serverless »
Plus de serveurs
En réalité, il y’a toujours des serveurs
derrière, mais ce n’est plus votre problème
des services SaaS, généralement fournis par
des outils Cloud, comme AWS
Si votre site est composé :
de pages statiques : c’est idéal, performant, et
simple à déployer
de pages avec du contenu dynamique : c’est
intéressant, mais très différent

26. Serverless : quel impact pour le SEO ?
En principe le site peut-être 100% compliant
En pratique… si le contenu est dynamique, c’est rarement
parfait
Utilisation excessive du javascript dans le navigateur
Balises SEO mal gérées (duplicates) ou absentes
Si le contenu est statique, c’est bon

27. Les « Single Page Applications »
Le principe : on développe un site web
comme une application.
On utilise des technos web (javascript, html,
serveurs web, https…) pour fabriquer une
application
Un seul code génère tout le contenu, pas
de notion de page web
Pour le SEO c’est une hérésie
Notion d’app : les développeurs sont tentés
de faire générer le contenu dans le
navigateur de l’internaute (mauvaise idée)
Une seule page au lieu de plusieurs :
absolument pas compatible SEO
On peut rendre ce type de code compatible, mais dans ce cas, on
ne peut plus appeler cela une SPA (ce n’est plus une app, et il y’a
plusieurs pages)

28. Les SPA, côté SEO, qu’est-ce que ça donne ?
Là on cumule plein de défauts gênants
pour le SEO
Risque d’impact négatif maximum !
Formellement déconseillé si le SEO est
stratégique pour vous
Important : reprenez vos développeurs
quand ils appellent votre site web fait
avec (au hasard) AngularJS une SPA
Si ce n’est pas une app
S’il y’a plusieurs pages

29. CSR, SSR, Hybrid
SSR : façon traditionnelle de faire un site
web
CSR : l’essentiel du contenu est généré
dans le navigateur de l’internaute
Danger potentiel pour le SEO
SPA
Hybride : une partie du contenu HTML
est généré côté serveur, une partie côté
client
Variante : SSR avec hydration
Potentiellement 100% compatible SEO

31. Les frameworks JS et le contenu généré en JS
VueJS, ReactJS, AngularJS et les autres…

32. La recommandation a changé
Google et Bing exécutent (plutôt bien) le code javascript côté client
Mais ils sont encore bien seuls
Les frameworks sont devenus « universels » : ils sont utilisables en SSR, en
CSR, et en hybride
Si utilisé en CSR : mauvais pour le SEO
Si utilisé en SSR : ok pour le SEO, c’est un site web normal
Si utilisé en Hybride : dépend de la bonne implémentation, mais c’est potentiellement
plutôt OK
Même chose pour l’hydration
On peut obtenir dorénavant des bons résultats avec ces technologies

33. Les « Progressive Web Apps »
Les sites « PWA » sont des pages web en
HTML5 (des pages web « normales »)
dont le code tire parti des fonctionnalités
avancées des navigateurs modernes pour
se comporter comme des apps
Sauvegarde locale de données / paramètres
Consultation hors ligne
Déclenchement d’alertes
Accès aux capteurs : GPS, APN…
Enregistrement d’un raccourci vers l’app
…
Cela évite de télécharger une app à part

34. Les PWA et le SEO
En théorie, un site PWA peut-être 100% compatible SEO
C’est même beaucoup mieux qu’une app.
Si on a besoin de faire indexer le contenu d’une app, il faut passer par l’app
indexing, obsolète et compliqué
Avec une PWA : cela s’indexe comme des pages normales
En pratique, tout dépend qui développe les PWA :
Si les devs sont habitués à faire des sites web : OK
Si les devs sont habitués à faire des apps : possible de récupérer un
code non compatible (site conçu comme une SPA et non comme un site
web « normal »)
VIGILANCE DE RIGUEUR

35. Conclusion
On vit une époque où les innovations foisonnent autour de la façon de construire des
sites web
Toutes ces nouvelles méthodes ne sont pas toujours parfaitement maîtrisées par les équipes
techniques, ce qui engendre un risque élevé pour le SEO
C’est néanmoins un handicap qui disparaîtra avec le temps
La plupart de ces méthodes 5(mais pas toutes) sont néanmoins 100% compatible SEO sur le papier
Il est donc possible d’avoir un bon référencement en les utilisant, à condition de veiller à ce que
l’implémentation soit parfaite
Le risque commun : oublier les règles fondamentales de la création de site web à l’occasion de
l’adoption d’une architecture nouvelle => pb de compatibilité SEO
Ne jouez pas avec le feu : faites vous accompagner par des spécialistes qui connaissent
ET le seo ET ces nouvelles technologies

36. Merci