Comment éviter le clickjacking et le CSRF sur votre site web

Lorsque l’on crée un site web, on pense souvent à l’apparence, aux fonctionnalités, aux pages qui se chargent vite, aux images bien compressées, et parfois même au référencement. Pourtant, l’un des aspects les plus importants reste très souvent relégué au second plan : la sécurité. Ce n’est pas forcément par négligence, mais parce que ce sujet peut paraître technique, complexe, ou réservé aux “experts en cybersécurité”.

Pourtant, il suffit parfois de quelques règles simples pour protéger un site contre des attaques fréquentes. Parmi ces attaques, deux ressortent très souvent : le clickjacking et le CSRF (Cross-Site Request Forgery). Ces deux failles sont discrètes, efficaces, et peuvent faire dire ou faire faire des actions à vos utilisateurs sans qu’ils s’en rendent compte. Autrement dit, quelqu’un pourrait utiliser votre site ou le compte de vos utilisateurs comme si c’était eux, mais sans leur consentement.

L’objectif de ce tutoriel est de vous guider, pas à pas, en partant de zéro, pour comprendre ces attaques par clickjacking ou CSRF, les reconnaître, et surtout les éviter. Vous n’avez pas besoin d’être ingénieur en cybersécurité. Nous allons tout expliquer avec des mots simples, des analogies, et des exemples concrets. L’idée est que vous puissiez repartir avec une véritable compréhension, et les outils nécessaires pour protéger vos propres projets.

Mettons-nous dans la peau d’un utilisateur

Imaginez que vous êtes connecté sur votre site bancaire en ligne. Vous laissez votre session ouverte, car vous êtes pressé. Pendant ce temps, vous naviguez sur un autre site, peut-être un forum ou un blog. Tout semble normal. Et pourtant, en arrière-plan, ce site peut envoyer une requête à votre banque en utilisant votre session toujours active. Résultat possible : un virement que vous n’avez jamais autorisé.

Ou bien, une bannière, apparemment innocente, pourrait vous faire cliquer sur un bouton… mais ce bouton, derrière les apparences, est en réalité un bouton d’action sur votre compte. C’est cela la définition du clickjacking.

Autrement dit, l’utilisateur pense agir sur une page, alors qu’il agit sur une autre, ou il ne fait rien du tout, mais une action est exécutée à sa place. C’est comme si, en regardant une vitrine, votre main se mettait à signer un chèque sans que vous le contrôliez.

Pour comprendre comment on en arrive là, il faut d’abord saisir les mécanismes qui permettent à ces attaques d’exister.

Comment effectuer un clickjacking : comprendre l’attaque par détournement de clic

Le mot clickjacking vient de l’anglais “click” (cliquer) et “hijacking” (détourner). L’idée est simple : vous cliquez sur quelque chose que vous pensez inoffensif, mais votre clic est redirigé vers une autre page, généralement cachée ou transparente.

Imaginez que vous regardiez une vidéo sur un site. L’attaquant superpose une couche invisible au-dessus de la vidéo, avec par exemple un bouton “Confirmer l’achat” provenant d’un autre site. Vous pensez cliquer sur pause. En réalité, vous validez un paiement.

D’où vient le problème ?
Les navigateurs autorisent par défaut l’intégration des pages dans des iframe, c’est-à-dire des fenêtres intégrées affichant une autre page web. Un attaquant peut donc charger votre page dans une iframe et la cacher sous un autre élément.

Exemple concret

Vous avez un tableau de bord pour administrer votre site. L’URL est par exemple :

https://mon-site.fr/admin/supprimer-compte?id=42

Si un utilisateur ayant accès à l’administration visite une page malveillante, cette page peut contenir :

<iframe src="https://mon-site.fr/admin/supprimer-compte?id=42" style="opacity: 0; position: absolute; z-index: 999; top: 0; left: 0; width: 100%; height: 100%;"></iframe>

Puis :

<button style="position:absolute; top:100px; left:100px; width:300px; height:100px; opacity:0;">Cliquez ici pour gagner un cadeau</button>

L’utilisateur voit un bouton “cadeau” mais clique en réalité sur le bouton invisible qui supprime un compte. C’est ça, le clickjacking. Simple, efficace, inquiétant.

Pourquoi cela fonctionne ?

Parce que les pages web ne disent rien au navigateur sur l’endroit où elles peuvent être affichées.

Sans directives de sécurité, votre site peut être affiché par n’importe qui, sous n’importe quelle forme.

Le CSRF : comprendre la falsification de requêtes

La seconde attaque majeure est le CSRF (Cross-Site Request Forgery), qu’on appelle souvent usurpation de requête inter-site.

Ici, l’objectif de l’attaquant est différent. Il ne cherche pas à vous faire cliquer, mais à utiliser votre session déjà authentifiée pour envoyer une action à votre place.

Lorsque vous vous connectez à un site, celui-ci enregistre votre session dans un cookie. Ce cookie permet au site de savoir que “oui, c’est bien vous”. Ainsi, pendant la durée de la session, vous n’avez pas besoin de vous reconnecter à chaque page.

Mais les navigateurs envoient automatiquement ces cookies lorsque vous faites une requête vers le site. Et le problème est là : même si la requête vient d’un site externe, le cookie est quand même envoyé.

Pour vous protéger, apprenez à Sécuriser les sessions PHP de votre site web.

Exemple concret

1. Vous êtes connecté à https://mon-banque.fr.
2. Vous allez ensuite sur https://site-malveillant.com.
3. Ce site contient un formulaire caché :

<form action="https://mon-banque.fr/virement" method="POST">
  <input type="hidden" name="compte_dest" value="123456789">
  <input type="hidden" name="montant" value="2000">
</form>
<script>document.forms[0].submit();</script>

Vous ne voyez rien.
Vous ne cliquez sur rien.
Mais la requête est envoyée.
Le cookie d’authentification est automatiquement envoyé.
La banque pense que c’est vous qui avez demandé le virement.

Voilà ce qu’est le CSRF : profiter de votre connexion existante pour vous faire faire quelque chose que vous n’avez jamais voulu faire.

En résumé, le clickjacking utilise la manipulation d’interface, le CSRF utilise la confiance du navigateur.

Les deux sont sournois. Les deux sont dangereux. Mais la bonne nouvelle, c’est que l’on peut se protéger.

Comment se protéger efficacement du clickjacking

Le clickjacking repose sur un principe simple : afficher votre site dans une iframe, puis manipuler son affichage et son interactivité. Pour empêcher cela, l’objectif est de dire au navigateur dans quelles conditions votre site a le droit d’être affiché à l’intérieur d’une iframe.

Aujourd’hui, trois méthodes principales existent. Les deux premières sont considérées comme standards et recommandées :

• L’en-tête HTTP X-Frame-Options
• La directive Content-Security-Policy (CSP), notamment frame-ancestors
• La troisième méthode, dite “anti-clic” via JavaScript, est moins sécurisée mais permet d’ajouter une couche supplémentaire.

Nous allons voir chacune d’elles, tranquillement, une par une.

Utiliser l’en-tête HTTP X-Frame-Options

L’en-tête X-Frame-Options indique au navigateur si votre page peut être chargée dans une iframe.

Il existe trois valeurs principales :

1. DENY
   Interdit totalement l’affichage de la page dans une iframe, peu importe l’origine.
2. SAMEORIGIN
   Autorise l’affichage dans une iframe seulement si l’iframe est sur le même domaine que votre site.
3. ALLOW-FROM https://example.com
   Autorise seulement un domaine spécifique à afficher votre page (attention, ce mode est désormais ancien et peu supporté).

Dans la majorité des cas, pour un site classique (blog, portfolio, site vitrine, espace membre), la valeur la plus simple et sûre est :

X-Frame-Options: DENY

Cela signifie clairement : Aucune page, aucun site, aucune iframe ne peut afficher ce contenu. C’est radical, mais efficace.

Si vous avez besoin d’intégrer certaines pages dans vos propres iframes (par exemple sur code.crea-troyes.fr), utilisez :

X-Frame-Options: SAMEORIGIN

Pour en savoir plus, consultez notre Guide complet pour sécuriser les headers HTTP.

Comment l’implémenter

Cela dépend de votre serveur.

Si vous utilisez Apache, ajoutez dans votre .htaccess :

Header always set X-Frame-Options "SAMEORIGIN"

Ou, si vous voulez interdire totalement :

Header always set X-Frame-Options "DENY"

Si vous utilisez Nginx, ajoutez dans votre configuration du site :

add_header X-Frame-Options "SAMEORIGIN";

Ou :

add_header X-Frame-Options "DENY";

Si vous développez en PHP

Vous pouvez également envoyer l’en-tête directement :

header("X-Frame-Options: SAMEORIGIN");

Cependant, il est préférable de passer par la configuration du serveur, afin que l’en-tête soit envoyé en toute circonstance, même si le code PHP n’est pas exécuté (par exemple pour une erreur ou un fichier statique).

Utiliser la directive CSP : frame-ancestors

Le Content-Security-Policy (CSP) est une évolution beaucoup plus flexible et moderne. Il permet notamment de spécifier où votre page peut être intégrée.

Par exemple, pour interdire totalement :

Content-Security-Policy: frame-ancestors 'none';

Pour autoriser seulement votre site :

Content-Security-Policy: frame-ancestors https://votre-site.fr;

Pour autoriser un sous-domaine spécifique :

Content-Security-Policy: frame-ancestors https://mon-app.votre-site.fr;

Pourquoi CSP est souvent préférable

L’en-tête X-Frame-Options fonctionne, mais il commence à être considéré comme “hérité”. La directive frame-ancestors est plus moderne, plus expressive et surtout mieux intégrée dans les politiques de sécurité avancées (CSP gère aussi scripts, images, styles, ressources externes, etc.)

Dans un monde idéal, vous envoyez les deux :

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self';

L’intérêt est double :

• Compatibilité maximale (anciens navigateurs + nouveaux)
• Couche de protection renforcée
  Un attaquant devra contourner deux barrières, ce qui complique déjà bien la tâche.

Ajouter une protection visuelle côté JavaScript (facultatif mais utile)

Il existe aussi une technique consistant à vérifier, en JavaScript, si votre page est actuellement affichée dans une iframe.

Exemple simple :

if (window.top !== window.self) {
  window.top.location = window.location;
}

Ce code force la page à s’ouvrir dans la fenêtre principale si elle est intégrée dans une iframe. Ce n’est pas infaillible : un attaquant peut désactiver JavaScript ou filtrer ce script. Mais c’est une couche en plus, et une défense multicouche est toujours plus robuste.

Lors d’une formation en entreprise, un développeur m’expliquait être persuadé que “ce genre d’attaque, ça n’arrive qu’aux grandes plateformes comme Facebook ou Google”. Pour lui, un site artisan, pourtant avec gestion d’espace client, ne risquait rien. Le lendemain, nous avons découvert sur son serveur logs que son tableau de bord administrateur avait été chargé dans des iframes provenant d’un site externe… Le pirate testait clairement la possibilité d’un clickjacking. Rien n’avait été compromis, mais la porte était grande ouverte.

Ce n’est pas une attaque théorique : elle existe réellement et les attaquants la tentent régulièrement, même sur des “petits sites”.

Résumons les protections contre le clickjacking

L’objectif est de dire au navigateur où votre site peut être affiché.

• Pour interdire l’affichage dans toutes les iframes :
  X-Frame-Options: DENY ou frame-ancestors 'none'
• Pour autoriser seulement votre domaine :
  X-Frame-Options: SAMEORIGIN ou frame-ancestors 'self'
• Pour autoriser seulement quelques partenaires :
  frame-ancestors https://site1.com https://site2.com
• En complément, une protection JS peut améliorer la robustesse.

Ces directives sont simples, faciles à mettre en place, et constituent déjà une défense solide, même pour un débutant.

Comment se protéger efficacement contre le CSRF

Vous avez compris que l’attaque CSRF repose sur un principe très simple : Le navigateur envoie les cookies automatiquement, même lorsqu’une requête provient d’un site tiers.

La clé pour empêcher cela consiste donc à vérifier que la requête a bien été envoyée volontairement par l’utilisateur, depuis votre site, et pas depuis l’extérieur.

Pour cela, il existe plusieurs méthodes, certaines très simples, d’autres un peu plus avancées. Nous allons les découvrir progressivement, en expliquant pourquoi elles fonctionnent, comment les appliquer, et comment être sûr qu’elles protègent réellement votre site.

Le principe du token anti-CSRF (ou jeton CSRF)

Le mécanisme le plus répandu, et de loin le plus fiable pour se protéger contre le CSRF, est le jeton CSRF.

L’idée est la suivante :

1. Lorsque l’utilisateur charge un formulaire depuis votre site, votre serveur génère un jeton unique, généralement aléatoire et impossible à deviner.
2. Ce jeton est envoyé au navigateur et stocké côté serveur.
3. Lorsque l’utilisateur envoie le formulaire, ce jeton est renvoyé dans la requête.
4. Le serveur compare le jeton reçu avec le jeton stocké.
   • Si les jetons correspondent, la requête est autorisée.
   • Si le jeton est absent, invalide ou incorrect, la requête est bloquée.

Pourquoi cela fonctionne ?
Parce qu’un site malveillant peut imiter votre formulaire, mais il ne pourra pas deviner le jeton, ni le récupérer, puisqu’il est stocké uniquement côté serveur et visible uniquement pour l’utilisateur réel.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

C’est comme si, pour signer un document, vous ajoutiez un mot secret inscrit au dos du contrat. Celui qui n’a pas le mot secret ne peut pas valider l’action.

Exemple simple en PHP

Imaginons un formulaire de changement de mot de passe. Dans votre code, lors de l’affichage du formulaire :

session_start();
$token = bin2hex(random_bytes(32)); // Génération sécurisée
$_SESSION['csrf_token'] = $token;

Puis dans le formulaire HTML :

<form method="POST" action="changer_mdp.php">
  <input type="password" name="nouveau_mdp">
  <input type="hidden" name="csrf_token" value="<?php echo $token; ?>">
  <input type="submit" value="Changer le mot de passe">
</form>

Dans changer_mdp.php

session_start();

if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
  die("Requête invalide");
}

// La requête est authentique, on peut ici modifier le mot de passe

Ici, un site malveillant peut bien tenter d’imiter le formulaire, mais il ne pourra jamais deviner ce token. Et sans token valide, votre serveur refuse simplement la requête.

Apprenez simplement à Créer un token en PHP.

Et si j’utilise un framework ?

Bonne nouvelle : pratiquement tous les frameworks modernes incluent déjà des protections CSRF.

Par exemple :

• Laravel : le middleware VerifyCsrfToken est activé par défaut.
• Symfony : les formulaires incluent csrf_protection => true.
• Django : l’annotation {% csrf_token %} dans les templates.
• Spring Security : CSRF activé automatiquement.
• Vue, React + API : utilisation de SameSite, tokens, et protections côté backend.

Si votre site est moderne, il se peut même que vous soyez déjà protégé sans le savoir. Mais encore faut-il comprendre ce qui se passe. D’où l’intérêt de ce tutoriel.

Utiliser l’attribut SameSite sur les cookies

Un autre moyen de limiter les attaques CSRF consiste à demander au navigateur de ne pas envoyer les cookies lors de requêtes provenant de sites externes.

Pour cela, on ajoute l’attribut SameSite aux cookies d’authentification.

Il existe trois valeurs :

• SameSite=Lax
  Le cookie n’est envoyé que lors de requêtes provenant du site lui-même, sauf pour les navigations simples (comme cliquer sur un lien). C’est un bon équilibrage entre sécurité et compatibilité.
• SameSite=Strict
  Le cookie n’est envoyé que si la requête vient directement de votre site.
  C’est la version la plus sécurisée, mais elle peut provoquer des déconnexions lorsque l’utilisateur navigue depuis des liens externes.
• SameSite=None; Secure
  Utilisé pour les sites accessibles en cross-domain (rarement nécessaire, sauf API avancée).
  Obligatoire : doit être accompagné de Secure (HTTPS indispensable).

Exemple en PHP moderne :

setcookie('session', $session_id, [
  'secure' => true,
  'httponly' => true,
  'samesite' => 'Lax'
]);

Même si un site malveillant tente d’envoyer une requête vers votre site, le cookie ne sera tout simplement pas envoyé.

Cela bloque la grande majorité des attaques CSRF les plus simples.

Découvrez Les cookie partitionnés avec PHP 8.5.

Vérifier l’en-tête Origin ou Referer

Une autre stratégie consiste à vérifier que la requête vient bien de votre domaine. Les navigateurs envoient automatiquement l’en-tête HTTP Origin ou Referer lors d’une requête.

Exemple simple :

if (parse_url($_SERVER['HTTP_ORIGIN'], PHP_URL_HOST) !== 'mon-site.fr') {
  die('Requête suspecte');
}

Attention cependant :

• Referer peut être supprimé ou masqué par certains navigateurs ou pare-feu.
• Origin n’est pas envoyé sur toutes les requêtes GET anciennes.

C’est une protection utile, mais à utiliser en complément, pas comme solution principale.

La double vérification côté client + côté serveur

Il faut retenir un point essentiel :

Une protection CSRF efficace ne peut jamais être uniquement côté client. Une validation JavaScript ne suffit pas, car le navigateur peut être manipulé. Le contrôle doit toujours inclure une validation côté serveur.

Autrement dit :

• Le client envoie des informations (comme le token CSRF).
• Le serveur vérifie qu’elles correspondent à ce qu’il attend.
• Si ce n’est pas le cas, la requête est refusée sans discussion.

C’est cette validation côté serveur qui rend l’attaque bien plus difficile, voire impossible.

Si vous avez déjà utilisé un site bancaire, vous avez peut-être remarqué un système surprenant lors des virements : Lorsque vous préparez un virement, un code unique vous est envoyé par SMS. Vous devez recopier ce code pour valider l’action. C’est une version “hors ligne” du token CSRF.

Sans ce code, la banque ne vous fait pas confiance. Le site web fonctionne de la même manière : Sans jeton CSRF, pas d’action !

Résumons les méthodes pour prévenir le CSRF

La sécurité se construit en couches :

• D’abord, on ajoute des tokens anti-CSRF dans les formulaires.
• Ensuite, on active SameSite sur les cookies.
• On peut également vérifier Origin et Referer.
• On évite les requêtes sensibles en GET (pas d’URL du type ?supprimer=1).
• On valide systématiquement côté serveur.

Si ces éléments sont combinés, l’attaque CSRF devient extrêmement difficile, voire irréaliste.

Les erreurs fréquentes et ce qu’il faut absolument éviter

Lorsqu’on découvre la sécurité web, on est souvent tenté d’appliquer rapidement des solutions trouvées sur Internet. Mais une protection mal comprise ou mal configurée peut donner une impression de sécurité, sans offrir de réelle protection. C’est parfois pire que de ne rien faire, parce qu’on baisse la garde.

Voici les erreurs que l’on rencontre le plus souvent.

Penser que l’attaque ne nous concerne pas

Il est très fréquent de croire que ces attaques visent seulement les “gros sites”. On pense souvent que personne ne va s’intéresser à son blog personnel, sa boutique locale ou son tableau de bord interne.

Pourtant, les attaques de type clickjacking et CSRF ne nécessitent aucune connaissance préalable du site. Elles sont automatisées, testées massivement, souvent sans ciblage humain. Les robots attaquent tout ce qui répond sur le web. Ils ne cherchent pas un site précis, ils cherchent une opportunité.

Si votre porte n’a pas de serrure, vous n’êtes pas visé personnellement. Vous êtes simplement vulnérable.

Croire qu’une vérification JavaScript suffit

JavaScript est facilement modifiable, désactivable, ou masquable. Une protection visible (comme un bouton grisé ou un message d’alerte) ne remplace jamais une validation côté serveur.

On peut utiliser JavaScript en complément, mais jamais comme seul mécanisme.

Utiliser la méthode GET pour des actions sensibles

Une faute assez courante consiste à déclencher des actions importantes via des URL du type :

https://mon-site.fr/admin/supprimer?id=32

Cela ouvre grand la porte au CSRF, car un pirate peut simplement forcer l’ouverture de cette URL.

Les actions sensibles doivent toujours être effectuées via la méthode POST, avec un contrôle CSRF. Si vous retenez une phrase de ce tutoriel, ce serait celle-ci :

Les actions qui modifient des données ne doivent jamais être effectuées via GET.

Ne pas protéger les API internes

De plus en plus de sites utilisent des appels API internes pour gérer des actions (exemple : un tableau de bord admin administré via JavaScript). On se dit : “l’API n’est pas publique, personne ne la voit”. Pourtant, si l’utilisateur est connecté, l’API répondra… et un attaquant pourra très facilement l’appeler via une page piégée.

Une API sécurisée exige :

• un système d’authentification
• un token CSRF si elle est appelée depuis un navigateur

Cas concrets : application dans un projet web réel

Pour que tout ceci soit concret, imaginons que vous développiez un espace membre, comme c’est le cas sur de nombreux sites modernes.

Votre application contient :

• Une page de connexion
• Une page de modification de profil
• Un bouton pour supprimer son compte
• Une option pour gérer des paiements (ou commandes, ou documents clients)

Voici ce qui se passerait en sécurisant progressivement votre site.

Étape 1 : Protéger les pages sensibles contre le clickjacking

Vous ajoutez dans votre configuration serveur :

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self';

Résultat concret :
Aucun autre site ne peut afficher vos pages dans une iframe. Donc, plus de possibilité de piéger l’utilisateur par superposition invisible. Le clickjacking est neutralisé.

Étape 2 : Protéger les formulaires contre le CSRF

Chaque formulaire qui modifie une donnée (changer email, changer avatar, ajouter un texte, supprimer un compte, etc.) inclut désormais un token CSRF.

Chaque action sensible est en POST. Les actions GET servent uniquement à afficher des pages. Les actions POST, elles, modifient des données et sont protégées par jeton.

Résultat : Même si un pirate tente une attaque en envoyant l’utilisateur sur une page piège, la requête sera refusée tant qu’elle n’a pas le bon jeton.

Étape 3 : Sécuriser les cookies

Vous ajoutez :

SameSite=Lax
Secure
HttpOnly

Résultat :

• Le cookie ne circule que sur HTTPS
• Il est inaccessible via JavaScript (donc plus difficile à voler)
• Il n’est plus envoyé automatiquement sur les requêtes venant de sites externes

Vous venez de renforcer la barrière contre le CSRF et contre le vol de session.

Ne vous dites jamais que les systèmes de sécurité, “c’est de la théorie, on ne va jamais assez vite pour les implémenter”. Supprimer tous les jetons CSRF pour aller plus vite en production, en pensant que “ça ira”.

En cas de piratage, cela coûtera plus cher en image et en temps que les quinze minutes qu’aurait pris un système CSRF correctement mis en place.

La morale : La sécurité est toujours plus rapide avant l’attaque qu’après.

Tableau récapitulatif : différences et protections

La sécurité web ne doit pas être vue comme une contrainte technique ou une étape abstraite. Elle est directement liée à la confiance que vos utilisateurs accordent à votre site. Le clickjacking et le CSRF ne sont pas des attaques spectaculaires, elles ne laissent pas d’alertes rouges clignotantes, elles ne cassent pas l’accès à vos pages. Elles sont silencieuses, subtiles, parfois invisibles.

C’est précisément ce qui les rend dangereuses.

Mais la bonne nouvelle, c’est que vous savez maintenant les reconnaître, les comprendre et les empêcher. Vous avez vu que les protections ne sont pas complexes, qu’elles reposent sur des principes logiques, cohérents et relativement simples à appliquer. Une ligne dans un .htaccess, un jeton dans un formulaire, une vérification côté serveur. Rien de tout cela n’exige de devenir un expert en cybersécurité.

Ce qui compte, c’est l’attention que l’on porte à ces détails. Et souvent, ce sont ces détails qui font toute la différence entre un site fragile et un site fiable.

En sécurisant vos pages contre l’affichage en iframe, en adoptant des tokens CSRF, en structurant vos requêtes entre GET et POST, vous ne faites pas seulement “protéger votre site” : Vous montrez à vos utilisateurs que leur confiance n’est pas un hasard. Elle est une valeur que vous prenez réellement au sérieux.

Alban

Fondateur de l’agence Créa-troyes.
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr