Core Web Vitals : optimisation LCP, INP, CLS 2026
L'optimisation des Core Web Vitals tient en 5 étapes opérationnelles applicables sans équipe technique dédiée. Mesurer LCP, INP et CLS via Search Console et Lighthouse en croisant données de terrain et données de laboratoire. Corriger d'abord le LCP (image héro en WebP, TTFB, preload) qui pèse pour 70% des échecs sur sites TPE. Alléger ensuite l'INP en supprimant les scripts tiers inutilisés. Stabiliser le CLS en réservant les dimensions des images et bannières. Suivre mensuellement pour éviter les régressions. Comptez 2 à 5 jours d'effort répartis sur 4 semaines pour une PME e-commerce.
Sommaire
- Pré-requis : ce qu'il faut avant d'optimiser ses Core Web Vitals
- Étape 1, Diagnostiquer ses Core Web Vitals avec Lighthouse et Search Console
- Étape 2, Corriger le LCP : la métrique qui pèse le plus
- Étape 3, Corriger l'INP : fluidité des interactions
- Étape 4, Corriger le CLS : stabilité visuelle
- Étape 5, Suivre ses Core Web Vitals dans la durée
- Erreurs fréquentes qui annulent l'optimisation des Core Web Vitals
- Questions fréquentes
Pré-requis : ce qu'il faut avant d'optimiser ses Core Web Vitals
Avant d'ouvrir Lighthouse, posez le cadre. Sans cadre, on tourne en rond entre 40 indicateurs et on ne corrige rien.
Connaître les 3 seuils à viser (LCP < 2,5s, INP < 200ms, CLS < 0,1)
Trois indicateurs racontent la performance perçue de votre site. Le LCP (vitesse d'affichage de la zone principale, généralement l'image ou le titre de hero) doit rester sous 2,5 secondes. L'INP (délai entre un clic et la réaction visible de la page) doit rester sous 200 millisecondes. Le CLS (stabilité visuelle : les éléments qui sautent pendant le chargement) doit rester sous 0,1.
Ces seuils ne sortent pas d'un chapeau. Ils sont définis par Google Search Central dans sa documentation officielle Core Web Vitals, basés sur les comportements observés sur des milliards de pages via le Chrome User Experience Report.
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP | < 2,5 s | 2,5 à 4 s | > 4 s |
| INP | < 200 ms | 200 à 500 ms | > 500 ms |
| CLS | < 0,1 | 0,1 à 0,25 | > 0,25 |
Avoir accès à Search Console et PageSpeed Insights
Deux comptes suffisent pour démarrer. Google Search Console (propriété vérifiée sur votre domaine) et PageSpeed Insights (accessible sans compte). Si votre site tourne sur WordPress ou Shopify, vérifiez aussi l'accès au back-office pour installer ou désactiver des extensions. Sans cet accès, vous diagnostiquerez sans jamais pouvoir corriger. Un constat brutal.
Identifier les pages à fort trafic à prioriser
Sur le terrain, je vois la même erreur revenir : un dirigeant qui veut "optimiser tout le site". Mauvaise idée. Concentrez vos efforts sur les 10 pages qui font 80% du trafic SEO. Allez dans Search Console, rapport "Performances", triez par clics descendants, exportez le top 10. C'est votre périmètre de travail. Le reste viendra plus tard.
Ce que ça change pour vous : sur une PME e-commerce d'environ 200 pages, ce cadrage transforme un chantier de 3 mois en un sprint de 3 jours étalés sur 4 semaines. Vous touchez 80% du SEO impactable avec 15% de l'effort.
Étape 1, Diagnostiquer ses Core Web Vitals avec Lighthouse et Search Console
Vous ne pouvez pas corriger ce que vous n'avez pas mesuré. Cette étape vous prend 90 minutes pour 10 pages.
Lire le rapport "Signaux Web essentiels" dans Search Console
Connectez-vous à Search Console. Menu de gauche, "Expérience" puis "Signaux web essentiels". Deux graphiques apparaissent : Mobile et Ordinateur. Concentrez-vous sur Mobile. Pourquoi ? Parce que Google indexe en mobile-first depuis 2021, et la majorité du trafic e-commerce français passe par le mobile selon le baromètre Médiamétrie 2025.
Le rapport classe vos URL en trois catégories : Bonnes, À améliorer, Médiocres. Cliquez sur "À améliorer" et "Médiocres" pour voir le détail. Google groupe les URL similaires ; si une URL est citée, ses voisines (même template) ont probablement le même problème.
Lancer un audit Lighthouse page par page
Ouvrez Chrome, allez sur une page à diagnostiquer, faites clic droit puis "Inspecter". Onglet "Lighthouse", cochez "Performance" et "Mobile", cliquez sur "Analyser". Vous obtenez un score de 0 à 100 et un détail métrique par métrique. Exportez le rapport en JSON ou HTML pour archive.
Faites ça pour vos 10 pages prioritaires. Comptez 3 minutes par page. Vous repartez avec une matrice claire de ce qui plante et où.
Distinguer données de terrain (CrUX) et données de laboratoire
C'est LA distinction que personne ne vous explique. Lighthouse fait une simulation : votre machine, votre connexion, à un instant T. Ce sont les données de laboratoire. Le Chrome User Experience Report (CrUX) agrège les données réelles des utilisateurs Chrome ayant accepté la collecte sur 28 jours glissants. Ce sont les données de terrain.
Google classe uniquement sur la donnée de terrain. Vous pouvez avoir un score Lighthouse à 95 et un CWV "à améliorer" dans Search Console. C'est fréquent. La doc officielle Chrome User Experience Report le confirme : seules les vraies sessions utilisateurs comptent pour le ranking.
Ce que ça change pour vous : ne célébrez jamais un bon score Lighthouse. Attendez 28 jours après vos corrections et regardez Search Console. C'est lui qui dit la vérité.
Étape 2, Corriger le LCP : la métrique qui pèse le plus
Sur les comptes que j'accompagne, le LCP est dans 7 cas sur 10 le coupable principal. Bonne nouvelle : c'est aussi le plus simple à corriger.
Identifier l'élément LCP avec Lighthouse
Dans votre rapport Lighthouse, la section "Largest Contentful Paint element" nomme précisément l'élément en cause. Dans 80% des cas pour un site WordPress ou Shopify TPE, c'est une image de hero. Dans 15%, un bloc de texte H1. Dans 5%, une vidéo en fond de page.
Optimiser l'image principale (format WebP, dimensions, lazy loading exclu pour LCP)
Trois corrections à faire dans cet ordre. D'abord, convertir l'image en WebP (format moderne 25 à 35% plus léger que JPEG à qualité égale). Sur WordPress, des extensions comme ShortPixel ou Imagify le font automatiquement ; sur Shopify, c'est natif depuis 2022.
Ensuite, redimensionner. Une image héro de 3000 px de large affichée à 1200 px gaspille 60% de poids. Servez la bonne taille à chaque appareil avec l'attribut srcset. Troisième point, et c'est contre-intuitif : ne mettez jamais de lazy loading sur l'image LCP. Le lazy loading retarde son chargement, donc dégrade le LCP. Réservez-le aux images sous la ligne de flottaison.
Sur un projet e-commerce l'an dernier (boutique mode, équipe de 12 personnes), passer une image héro JPEG de 820 Ko à un WebP de 145 Ko a fait gagner 1,1 seconde de LCP en moyenne sur connexion 4G. Une seule action, un gain massif.
Réduire le temps serveur (TTFB) et précharger les ressources critiques
Le TTFB (Time to First Byte, le temps entre votre clic et la première réponse du serveur) doit rester sous 800 ms. Au-delà, votre hébergement est en cause. Sur WordPress mutualisé bas de gamme, le TTFB dépasse souvent 1,5 seconde. Passer sur un hébergement avec cache serveur intégré (O2switch, Kinsta, ou équivalents) divise ce chiffre par 2 à 3.
Ajoutez ensuite une balise <link rel="preload"> sur votre image LCP. Vous dites au navigateur : "charge ça en priorité". Gain typique : 200 à 400 ms supplémentaires.
| Levier LCP | Effort | Gain moyen | Pour qui |
|---|---|---|---|
| Image héro en WebP | 1h | 0,8 à 1,2 s | Tous |
| Redimensionnement srcset | 2h | 0,3 à 0,5 s | Tous |
| Hébergement avec cache | 1 jour | 0,5 à 1 s | TTFB > 1s |
| Preload ressources | 30 min | 0,2 à 0,4 s | LCP image |
Ce que ça change pour vous : un site PME qui passe de 4,2 s à 1,9 s de LCP gagne typiquement 10 à 15% de taux de conversion mobile, selon les benchmarks publiés par HTTP Archive dans le Web Almanac 2024. Pour un site qui fait 50 000€ de CA mensuel, on parle de 5 000 à 7 500€ par mois sans dépenser un euro en pub.
Étape 3, Corriger l'INP : fluidité des interactions
L'INP a remplacé FID en mars 2024 et reste mal compris en 2026. Beaucoup de sites qui passaient FID échouent à l'INP, parce que la nouvelle métrique est beaucoup plus exigeante.
Repérer les scripts tiers lourds (chat, analytics, A/B testing)
L'INP mesure le temps que met votre page à répondre à un clic, un tap ou une frappe clavier. Le coupable numéro un sur sites TPE/PME : les scripts tiers. Meta Pixel, Hotjar, chatbots Crisp ou Tawk.to, A/B testing Convertize, popups Sumo. Chacun ajoute 30 à 150 ms de blocage du thread principal.
Faites l'inventaire. Dans Chrome DevTools, onglet "Performance", enregistrez 10 secondes d'interaction et regardez les "Long Tasks". Vous verrez précisément quel script consomme votre INP. Quand j'audite une PME e-commerce, je trouve en moyenne 8 à 12 scripts tiers actifs, dont 3 à 5 inutilisés depuis des mois.
Différer ou supprimer le JavaScript non critique
Trois actions concrètes. Supprimez les scripts dont vous ne lisez pas les données (un Hotjar installé en 2023 et jamais consulté : à virer). Différez les scripts avec defer ou async ; ils se chargent après l'interaction critique. Passez par Google Tag Manager pour centraliser tout ça et déclencher les tags après le DOMContentLoaded plutôt qu'à l'ouverture.
La règle des 3 questions avant d'ajouter un nouveau script tiers : (1) Qui regardera ces données ? (2) À quelle fréquence ? (3) Quelle décision sera prise sur la base de ces données ? Si l'une des trois réponses est floue, vous n'ajoutez pas le script.
Cette logique de croisement des données est exactement ce qu'on creuse dans notre méthode d'analyse de données web pour TPE/PME : moins de tags, mieux exploités.
Tester l'INP sur mobile en conditions réelles
L'INP est très différent entre desktop et mobile. Un smartphone milieu de gamme (CPU bridé, RAM limitée) galère 3 à 5 fois plus qu'un MacBook Pro. Installez l'extension Chrome "Web Vitals", activez-la sur votre téléphone via Chrome distant, naviguez sur votre site. Vous voyez l'INP en temps réel.
Récemment, j'ai vu un dashboard client (TPE dans le BTP, une vingtaine de pages) afficher un INP correct sur desktop et catastrophique sur mobile, uniquement à cause d'un widget de chat chargé de façon synchrone. Deux lignes de config dans Tag Manager, problème résolu.
Ce que ça change pour vous : dans la pratique sur les comptes audités, supprimer 2 à 3 scripts marketing inutilisés fait gagner 80 à 150 ms d'INP. C'est souvent ce qui fait basculer un site de "À améliorer" à "Bon" dans Search Console.
Étape 4, Corriger le CLS : stabilité visuelle
Le CLS est le plus simple à corriger mais le plus négligé. Trois causes couvrent 90% des cas observés sur sites PME.
Réserver les dimensions des images et iframes
Quand une image se charge sans dimensions déclarées, le navigateur ne réserve pas son espace. Quand elle arrive, elle pousse le contenu en dessous. Décalage. Frustration. CLS qui explose.
Solution : sur chaque balise <img>, ajoutez width et height en pixels (pas en %). Même chose pour les <iframe> (YouTube embarqué, Google Maps). Le navigateur réserve l'espace et plus rien ne saute. Sur WordPress moderne, c'est automatique depuis la version 5.5 ; sur les vieux thèmes, ça peut nécessiter une refonte du template.
Maîtriser les polices web (font-display swap)
Les polices Google Fonts chargées par défaut provoquent un FOIT (Flash of Invisible Text) ou un FOUT (Flash of Unstyled Text) : la police de secours s'affiche, puis la vraie police arrive et tout le texte se recale.
Ajoutez font-display: swap dans votre CSS et choisissez une police de secours proche en métrique. Avec l'outil officiel web.dev pour comparer les polices, vous trouvez la combinaison qui ne décale rien.
Bannir les bannières et pop-ups qui décalent le contenu
Les bandeaux cookies mal codés, les bannières promo qui descendent en haut de page, les pop-ups qui poussent le contenu : tueurs de CLS. Solution : utilisez position: fixed ou position: absolute pour ces éléments. Ils flottent au-dessus du contenu sans le pousser.
L'an dernier sur un site e-commerce mode, j'ai vu un CLS passer de 0,28 à 0,06 simplement en repositionnant une bannière promo insérée en position: static au-dessus du header. Une ligne de CSS, deux semaines plus tard Search Console basculait en vert.
| Cause CLS | Symptôme visible | Correction | Niveau tech |
|---|---|---|---|
| Images sans dimensions | Texte qui saute | width/height en HTML | Facile |
| Polices web | Texte qui se recale | font-display: swap | Moyen |
| Bandeau cookies | Contenu poussé | position: fixed | Facile |
| Pubs dynamiques | Blocs qui apparaissent | Conteneur min-height | Moyen |
Ce que ça change pour vous : un CLS sous 0,1 n'améliore pas seulement le SEO. Il réduit aussi le taux de rebond mobile, parce que personne n'aime cliquer sur le mauvais bouton quand la page a sauté. Comptez 5 à 10% de réduction du taux de rebond après correction.
Étape 5, Suivre ses Core Web Vitals dans la durée
Le piège classique : on optimise une fois, puis tout repart en arrière au prochain ajout de plugin ou de tag marketing. Un rituel mensuel évite ça.
Mettre en place un suivi mensuel (Search Console + Lighthouse)
Bloquez 1 heure par mois dans votre calendrier. Le 1er lundi du mois fonctionne bien. Trois choses à faire : capture du rapport Signaux Web Essentiels de Search Console, audit Lighthouse sur vos 5 pages top trafic, comparaison avec le mois précédent dans un tableur simple.
Pour aller plus loin sur la méthode d'analyse périodique, notre guide complet d'analyse Google Analytics détaille comment croiser ces indicateurs avec les données business GA4.
Définir des alertes en cas de régression
Vous ne pouvez pas surveiller manuellement 24/7. Les outils de monitoring (Calibre, SpeedCurve, ou les fonctions natives de certaines stacks SaaS) envoient un email dès qu'une métrique dérape. Définissez des seuils d'alerte 10% en dessous de vos objectifs : si le LCP dépasse 2,75 s, vous êtes prévenu avant que Search Console ne bascule en rouge.
Documenter chaque mise en prod
Tenez un journal simple. Date, action effectuée (nouveau plugin, nouveau tag, refonte template), impact attendu. Quand vous voyez une régression CWV, vous croisez avec le journal et vous trouvez la cause en 5 minutes au lieu de 5 heures.
En début 2026, un client TPE (cabinet de conseil, site vitrine d'une trentaine de pages) m'a dit avoir perdu 3 semaines à chercher une régression de LCP. La cause : un plugin de formulaire ajouté par son assistante sans entrée dans le journal. Depuis, le journal est tenu.
Ce que ça change pour vous : ce rituel mensuel transforme l'optimisation en habitude plutôt qu'en chantier ponctuel. Vous ne paierez plus jamais un audit externe à 2 000€ pour vous dire "vos images sont trop lourdes". Vous le saurez avant.
Erreurs fréquentes qui annulent l'optimisation des Core Web Vitals
Six erreurs reviennent systématiquement quand j'audite des sites PME qui ont "déjà optimisé".
Erreur 1 : optimiser le score Lighthouse sans regarder les données de terrain. Symptôme : score à 95 en labo, CWV "à améliorer" dans Search Console. Cause : votre Lighthouse simule une connexion idéale et un appareil moyen, vos vrais utilisateurs sont sur 4G dégradée avec un Android d'entrée de gamme. Correctif : regardez Search Console, pas Lighthouse.
Erreur 2 : installer un plugin "tout-en-un" qui casse l'affichage. Symptôme : votre site est plus rapide mais le menu mobile ne s'ouvre plus. Cause : les plugins de cache agressifs minifient le JavaScript et cassent les dépendances. Correctif : tester chaque réglage isolément, garder uniquement ceux qui marchent sans régression.
Erreur 3 : négliger le mobile alors que Google indexe mobile-first. Symptôme : le site est parfait sur desktop, médiocre sur mobile. Cause : tests faits uniquement sur ordinateur. Correctif : tous les tests Lighthouse en mode mobile, point.
Erreur 4 : croire que le CDN résout tout. Symptôme : Cloudflare activé mais LCP toujours médiocre. Cause : le CDN accélère la livraison statique mais ne corrige pas une image trop lourde ou un script bloquant. Correctif : optimiser à la source, le CDN n'est qu'un accélérateur.
Erreur 5 : optimiser une fois et oublier. Symptôme : 6 mois après l'optimisation, retour à la case départ. Cause : ajouts successifs de plugins et tags marketing. Correctif : le rituel mensuel de l'étape 5.
Erreur 6 : refonte complète au lieu de corrections ciblées. Symptôme : devis à 15 000€ pour "refondre le site". Cause : prestataire qui surévalue le besoin. Correctif : 80% des problèmes CWV se règlent sans refonte. Demandez d'abord un audit de site internet ciblé avant tout chantier lourd.
Ce que ça change pour vous : éviter ces 6 erreurs vous économise typiquement 60% du budget d'optimisation d'un prestataire externe. Vous appliquez la méthode en interne et vous gardez le contrôle.
Industrialiser le suivi Core Web Vitals avec Lysible
Le rituel mensuel décrit dans ce guide fonctionne. Sauf que tenir dans la durée, sans oublier une page, sans rater une régression, c'est là que beaucoup de PME sans équipe tech dédiée décrochent au bout de 3 mois.
Lysible centralise Lighthouse, Search Console et GA4 dans un tableau de bord unique pensé pour les TPE/PME. Vous voyez vos Core Web Vitals évoluer mois après mois sur l'ensemble de vos pages top trafic, avec des alertes automatiques en cas de dégradation et un reporting mensuel prêt à présenter en comité de direction. Pour aller plus loin sur l'automatisation, notre guide sur l'audit SEO automatisé détaille le workflow hybride IA + monitoring qui sous-tend cette approche.
Questions fréquentes
Comment tester ses Core Web Vitals gratuitement ?
Trois outils gratuits suffisent. PageSpeed Insights (pagespeed.web.dev) vous donne un score en 30 secondes pour n'importe quelle URL publique, avec données labo et terrain. Google Search Console (gratuit avec propriété vérifiée) fournit le rapport "Signaux Web Essentiels" sur l'ensemble de votre site avec données de terrain CrUX agrégées sur 28 jours. Chrome DevTools (intégré au navigateur) permet de lancer Lighthouse en local et de mesurer en conditions contrôlées. Pour un suivi continu sans coût, l'extension Chrome "Web Vitals" affiche les trois métriques en temps réel pendant la navigation. Ces outils couvrent 95% des besoins d'une PME.
Pourquoi mon évaluation Core Web Vitals échoue-t-elle malgré un bon score PageSpeed ?
Parce que Google classe uniquement sur les données de terrain (Chrome User Experience Report), pas sur les données de laboratoire de Lighthouse. Lighthouse simule une session idéale sur une machine standardisée. Vos vrais utilisateurs naviguent depuis des smartphones milieu de gamme sur 4G dégradée, parfois 5G, avec extensions et antivirus actifs. L'écart est fréquent : score Lighthouse à 95, CWV "à améliorer" dans Search Console. La règle : ne vous fiez jamais au score Lighthouse pour le SEO, regardez uniquement le rapport "Signaux Web Essentiels" de Search Console basé sur les vraies sessions de vos utilisateurs Chrome.
Quels sont les seuils à viser pour LCP, INP et CLS en 2026 ?
Les seuils Google sont stables depuis l'arrivée de l'INP en mars 2024. LCP (Largest Contentful Paint, vitesse d'affichage de la zone principale) doit rester sous 2,5 secondes. INP (Interaction to Next Paint, délai de réaction après clic) doit rester sous 200 millisecondes. CLS (Cumulative Layout Shift, stabilité visuelle) doit rester sous 0,1. Au-delà, Google considère l'URL comme "à améliorer" entre 2,5 et 4s pour LCP, 200 à 500ms pour INP, 0,1 à 0,25 pour CLS. Plus loin encore, la mention "Médiocre" apparaît. Pour qu'une URL passe l'évaluation globale, 75% des sessions utilisateurs doivent respecter les trois seuils simultanément sur 28 jours glissants.
Combien de temps faut-il pour optimiser les Core Web Vitals d'un site PME ?
Comptez 2 à 5 jours d'effort répartis sur 4 semaines pour un site e-commerce de 150 à 300 pages. Décomposition typique : 1 demi-journée de diagnostic et cadrage, 1 jour de corrections LCP (images, hébergement, preload), 1 jour de nettoyage INP (audit scripts tiers, suppression des trackers inutilisés), 0,5 jour de corrections CLS (dimensions images, polices, bannières), 0,5 jour de tests et validation. L'étalement sur 4 semaines permet à Google de recalculer les données de terrain CrUX. Pour un site vitrine de moins de 50 pages, comptez 1 à 2 jours d'effort total. Un site WordPress sur mutualisé bas de gamme peut nécessiter 1 jour supplémentaire pour la migration d'hébergement.
L'INP a-t-il vraiment remplacé le FID et qu'est-ce que ça change ?
Oui, l'INP a remplacé le FID (First Input Delay) en mars 2024 comme métrique officielle Core Web Vitals. Le changement est majeur. Le FID ne mesurait que le délai du premier clic, ce qui était facile à optimiser. L'INP mesure le pire délai de réaction sur l'ensemble de la session utilisateur, ce qui est beaucoup plus exigeant. Conséquence concrète : beaucoup de sites qui passaient le FID sans souci échouent désormais à l'INP, notamment ceux chargés de scripts marketing (chatbots, A/B testing, pixels publicitaires). Les sites e-commerce sont particulièrement touchés. La correction passe par l'audit et le nettoyage systématique des scripts tiers, et le report du chargement après l'interaction critique.
Les Core Web Vitals impactent-ils vraiment le référencement Google ?
Oui, mais avec nuance. Google a confirmé en mai 2021 que les Core Web Vitals font partie des signaux de "Page Experience" utilisés pour le classement. L'impact n'est pas écrasant comme la pertinence du contenu ou les backlinks, mais devient décisif à pertinence égale. Sur les requêtes concurrentielles où plusieurs résultats répondent bien à l'intention, les Core Web Vitals départagent. Pour une PME, l'impact business est souvent plus fort sur le taux de conversion que sur le classement pur : un LCP qui passe de 4s à 2s améliore typiquement le taux de conversion mobile de 10 à 15% selon les benchmarks Web Almanac. Le SEO en bénéficie en bonus.
Quels outils utiliser pour suivre ses Core Web Vitals dans la durée ?
Pour démarrer gratuitement : Google Search Console (rapport mensuel automatique) + audits Lighthouse manuels sur vos 5 pages top trafic. Pour automatiser sans coder : extension Chrome "Web Vitals" pour tests rapides, WebPageTest pour des tests poussés. Pour les structures qui veulent industrialiser : des solutions de monitoring SaaS comme Calibre, SpeedCurve ou des plateformes françaises comme Lysible permettent de centraliser Lighthouse, Search Console et GA4 dans un tableau de bord unique avec alertes automatiques en cas de régression. L'avantage du SaaS : vous gardez l'historique mois par mois, ce qui est précieux pour identifier les régressions liées aux mises en prod successives.
Faut-il un développeur pour corriger ses Core Web Vitals ?
Non pour 80% des corrections, oui pour les 20% restantes. Les actions accessibles sans développeur : compresser et convertir les images en WebP (plugins WordPress comme ShortPixel), désactiver les scripts marketing inutilisés, ajouter des dimensions aux images via l'éditeur de contenu, repositionner une bannière promo en position: fixed. Les actions qui nécessitent un développeur ou un intégrateur : préchargement de ressources critiques en HTML, refonte du chargement des polices web, optimisation du JavaScript thread principal, mise en place de CSS critique inline. Le bon réflexe : faire d'abord les 80% accessibles, mesurer le résultat, puis arbitrer si l'investissement développeur se justifie pour les 20% restants.
Isaac SIKORSKI
Avec Lysible, je veux redonner aux entreprises le contrôle de leur présence en ligne, parce qu'un site internet bien compris, c'est un site qui génère vraiment des opportunités.
