Guides

Guides18 min de lecture

Comment arrêter le spam sur un formulaire de contact

Arrêtez le spam des formulaires de contact avec des couches invisibles pour les vrais visiteurs : honeypot, délai, score du contenu, limites de débit, vérification humaine si besoin.

Preet SutharFondateur, Ikiform

Empilez des vérifications peu coûteuses et invisibles avant d'ajouter la moindre friction : un champ honeypot masqué, un délai minimum pour remplir le formulaire, un score pour les liens et les formules de spam, et une limite de débit par visiteur. N'ajoutez une vérification humaine comme Cloudflare Turnstile que si du spam passe encore, et vérifiez son token sur un serveur. Conservez ce que vous attrapez au lieu de le jeter, pour pouvoir repêcher le rare vrai message.

Un formulaire de contact sur une page publique commence à recevoir des déchets quelques jours après son indexation. La plupart ne vous visent pas. Des scripts parcourent le web à la recherche du moindre <form>, remplissent chaque input et l'envoient, en espérant qu'un lien atterrisse quelque part. Une part plus petite vient de vrais navigateurs pilotés par un logiciel, et une partie de personnes payées pour coller le même argumentaire dans des milliers de formulaires. Chaque type s'arrête avec une vérification différente : c'est pourquoi une seule astuce ne règle jamais le problème.

Ce guide explique chaque défense, ce qu'elle attrape et ce qu'elle coûte aux vrais visiteurs, avec du code à exécuter sur n'importe quelle stack. Il montre ensuite comment Ikiform, un backend de formulaires, applique ces mêmes couches pour vous.

Des couches, de la moins coûteuse à la plus coûteuse

Classez les vérifications selon leur coût. Compter les requêtes ne coûte presque rien : cela passe donc avant toute lecture du corps. Les vérifications qui appellent un autre service, comme un captcha, s'exécutent une fois les moins coûteuses passées. Le score du contenu vient en dernier, car il a besoin des champs analysés. Ikiform exécute ses vérifications dans cet ordre sur chaque envoi.

L'ordre des vérifications anti-spam, de l'arrivée d'un envoi à son stockage ou au spamRefusé d'embléeNoté, puis stocké dans tous les casun envoiarrived'une page,d'un script oud'un serveurlimite dedébittrop d'un mêmevisiteur :429domainesautorisésenvoyé depuisun autresite ?vérif.humainetokenTurnstile, siactivéehoneypotrempli : +5délai etcontenutrop rapide,liens,formules,répétitionsscore de5 ouplus ?reçue-mails etwebhookspartentspammême réponsede succès,rien n'estenvoyédécompteoriginejetonnonouiL'ordre des vérifications anti-spam, de l'arrivée d'un envoi à son stockage ou au spamRefusé d'embléeNoté, puis stocké dans tous les casun envoi arrived'une page, d'unscript ou d'unserveurlimite de débittrop d'un mêmevisiteur : 429domainesautorisésenvoyé depuis unautre site ?vérif. humainetoken Turnstile, siactivéehoneypotrempli : +5délai et contenutrop rapide, liens,formules,répétitionsscore de 5ou plus ?reçue-mails et webhookspartentspammêmeréponse desuccès,rien n'estenvoyédécompteoriginejetonnonoui
  1. Un envoi arrive sur l'endpoint du formulaire.
  2. La limite de débit compte d'abord les envois par visiteur. Un flot est refusé avec 429 avant la lecture du corps.
  3. Les domaines autorisés comparent la page d'où vient l'envoi avec les domaines que vous avez listés.
  4. Si la vérification humaine est activée, l'envoi doit porter un token Turnstile valide.
  5. Le honeypot ajoute 5 au score lorsqu'il est rempli.
  6. Le délai, les liens, les formules de spam connues, les adresses jetables et les répétitions ajoutent de plus petites valeurs.
  7. À 5 ou plus, l'envoi est stocké comme spam. En dessous, l'envoi est reçu et vos e-mails et webhooks partent.
La ligne du haut refuse les envois. La ligne du bas ne refuse jamais : elle attribue un score, donc un faux positif se restaure d'un clic, sans message perdu.

Les défenses comparées

Chaque défense a un prix. Le tableau dit franchement ce que chacune laisse passer et ce qu'elle demande aux personnes dont vous voulez avoir des nouvelles.

DéfenseArrêteLaisse passerCoût pour les vrais visiteurs
HoneypotLes scripts qui remplissent chaque inputLes bots qui lisent le CSS ou ignorent les champs masqués, et les humainsAucun, s'il est masqué aux lecteurs d'écran et au remplissage automatique
Piège temporelLes envois faits plus vite que quiconque ne peut taperLes bots lents, et ceux qui attendentAucun, tant que le minimum est de quelques secondes
Score du contenu, comme le nombre de liens, les formules de spam ou AkismetLes démarchages SEO, dépôts de liens, spam de casino et de médicamentsLe spam d'apparence propre, et il peut signaler un vrai message contenant des liensAucun, si vous relisez ce qu'il attrape
Rate limitingLes flots et les scripts en boucleLe spam lent et étalé dans le tempsDes bureaux ou des événements derrière une seule IP peuvent atteindre une limite serrée
Domaines autorisésLes envois faits directement vers votre endpoint depuis ailleursLes scripts qui falsifient l'en-tête OriginAucune
Cloudflare TurnstileLa plupart des navigateurs automatisésLes spammeurs humains rémunérésGénéralement invisible. Parfois un clic, et il faut un script
reCAPTCHA ou hCaptchaLa plupart des navigateurs automatisésLes spammeurs humains rémunérés et les services de résolutionDes puzzles d'images pour certains visiteurs, plus un script tiers

Commencez par les cinq premières. Elles sont invisibles et attrapent l'essentiel de ce que reçoit un petit site. Ajoutez une vérification humaine quand le tableau de bord vous montre que du spam passe encore, pas avant : c'est la seule couche dont chaque visiteur peut sentir le coût. La page sur arrêter le spam sans captcha montre jusqu'où vont les couches invisibles à elles seules.

Lire le spam avant de le combattre

Regardez dix messages de spam avant de choisir une solution. Ce qu'ils ont en commun vous dit qui les envoie, et cela indique la couche qui les arrête.

De l'apparence du spam à la couche qui l'arrêtetexte aléatoirepartoutun bot scriptéanalyse le HTML, remplittouthoneypotdes dizaines/min,une sourceun script en bouclelimite de débitenvois soignés enmoins d'1 sun navigateurheadlesspiège temporel,vérif. humainedémarchages polisavec liensune personne, payéeau formulairescore du contenu,relectureCe que vous voyezQui l'envoieCe qui l'arrêteDe l'apparence du spam à la couche qui l'arrêtetexte aléatoire partoutun bot scriptéanalyse le HTML, remplit touthoneypotdes dizaines/min, unesourceun script en bouclelimite de débitenvois soignés en moinsd'1 sun navigateur headlesspiège temporel, vérif.humainedémarchages polis avecliensune personne, payée auformulairescore du contenu,relecture
  1. Du texte aléatoire dans chaque champ vient d'un script qui remplit tous les inputs. Un honeypot l'attrape.
  2. Des dizaines d'envois par minute depuis une même source viennent d'un script en boucle. Une limite de débit l'arrête.
  3. Des envois soignés faits moins d'une seconde après le chargement de la page viennent d'un navigateur headless. Un piège temporel ou une vérification humaine l'arrête.
  4. Des démarchages polis avec des liens viennent de personnes payées au formulaire. Seuls le score du contenu et votre propre relecture les attrapent.
Aucun captcha n'arrête la dernière ligne. Une personne peut le résoudre : le score du contenu et un coup d'œil hebdomadaire au dossier de spam sont donc la seule défense.

Un formulaire de contact avec les couches en place

Voici un formulaire de contact, construit pour chaque stack. Chaque version a le honeypot hors écran et une vérification humaine. Les versions 100 % navigateur utilisent la vérification Turnstile gérée par Ikiform, qui ne demande aucune clé. Les versions serveur montrent la voie à faire soi-même : votre serveur vérifie un token Turnstile avec vos propres clés Cloudflare, puis transmet les champs. Choisissez votre stack ci-dessous ; le choix s'applique à tous les exemples de code de ces guides.

Les onglets serveur partagent deux petits helpers. verifyTurnstile demande à Cloudflare si un token est authentique, et sendToIkiform transmet les champs avec votre clé secrète et l'en-tête Origin du visiteur. Un fetch côté serveur n'envoie pas d'Origin propre, et Ikiform le lit pour reconnaître un test gratuit depuis localhost. Les deux échouent de manière fermée : si Cloudflare est injoignable, le visiteur voit une erreur plutôt qu'un passage silencieux.

lib/spam.ts
const SITEVERIFY = "https://challenges.cloudflare.com/turnstile/v0/siteverify";
const ENDPOINT = "https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx";

export interface Contact {
  name: string;
  email: string;
  message: string;
  _gotcha: string;
}

export function readContact(data: FormData): Contact {
  return {
    name: String(data.get("name") ?? "").trim(),
    email: String(data.get("email") ?? "").trim(),
    message: String(data.get("message") ?? "").trim(),
    _gotcha: String(data.get("_gotcha") ?? ""),
  };
}

export async function verifyTurnstile(input: { secret: string; token: string; ip?: string | null }) {
  if (!input.token || input.token.length > 2048) return false;
  const body = new URLSearchParams({ secret: input.secret, response: input.token });
  if (input.ip) body.set("remoteip", input.ip);
  try {
    const response = await fetch(SITEVERIFY, { method: "POST", body });
    const result = (await response.json()) as { success?: boolean };
    return result.success === true;
  } catch {
    return false;
  }
}

export async function sendToIkiform(secretKey: string, contact: Contact, origin?: string | null) {
  try {
    const response = await fetch(ENDPOINT, {
      method: "POST",
      headers: {
        Accept: "application/json",
        "Content-Type": "application/json",
        Authorization: `Bearer ${secretKey}`,
        ...(origin ? { Origin: origin } : {}),
      },
      body: JSON.stringify(contact),
    });
    const result = await response.json().catch(() => null);
    if (result?.ok) return { ok: true as const };
    const fields: Record<string, string[]> = result?.error?.fields ?? {};
    const first = Object.values(fields)[0]?.[0];
    return {
      ok: false as const,
      status: response.status,
      message: String(first ?? result?.error?.message ?? "Couldn't send your message. Try again."),
    };
  } catch {
    return { ok: false as const, status: 502, message: "Couldn't reach the form service. Try again." };
  }
}

Le formulaire simple ne demande aucun script. Réglez le Spam check du formulaire Ikiform sur Ikiform, et un envoi sans token reçoit une courte page de vérification sur ikiform.com qui exécute Turnstile et transmet les champs. Les personnes qui la passent de façon invisible ne s'en aperçoivent jamais.

contact.html
<form action="https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx" method="POST">
  <label for="name">Name</label>
  <input id="name" name="name" autocomplete="name" required maxlength="120" />

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required />

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="5" required minlength="10" maxlength="5000"></textarea>

  <div class="hp" aria-hidden="true">
    <label for="hp-field">Leave this empty</label>
    <input id="hp-field" name="_gotcha" type="text" tabindex="-1" autocomplete="off" />
  </div>

  <button>Send message</button>
</form>

<style>
.hp {
  position: absolute;
  left: -10000px;
  width: 1px;
  height: 1px;
  overflow: hidden;
}
</style>

Le honeypot est placé hors écran plutôt que derrière display: none, car certains bots ignorent les champs masqués de cette façon. L'aria-hidden du conteneur et le tabindex de l'input tiennent les lecteurs d'écran et le clavier à l'écart.

  • Chaque version utilise la classe .hp du bloc de style de l'onglet HTML. Placez-la dans votre CSS global.
  • Le honeypot s'appelle _gotcha, le nom par défaut d'Ikiform. Les versions serveur le transmettent tel quel : un honeypot rempli atterrit donc quand même dans votre dossier de spam avec la raison honeypot.
  • Turnstile ajoute au formulaire un input masqué cf-turnstile-response. Un token est valable 300 secondes et ne sert qu'une fois : chaque tentative en demande donc un nouveau.
  • Les clés de test de Cloudflare vous permettent de tout exécuter en local. Le guide Turnstile les liste.
Les versions côté serveur envoient avec une clé secrète, donc Ikiform ignore Allowed domains et sa vérification humaine. Chaque envoi vient alors de l'IP de votre serveur, et la limite Standard de 5 par minute et par visiteur compte tous vos visiteurs ensemble. Choisissez la limite de débit Relaxed ou Custom pour un formulaire que vous envoyez via un serveur, et gardez IKIFORM_SECRET_KEY dans des variables d'environnement réservées au serveur.

Essayez la définition de champs ci-dessous. Elle exécute le validateur d'Ikiform dans votre navigateur, avec les mêmes règles que celles appliquées par le serveur avant tout calcul de score de spam.

Aperçu

Exécute le validateur d'Ikiform dans votre navigateur. Rien n'est envoyé.

Les mêmes champs que le modèle de formulaire de contact. Collez la définition dans l'onglet Fields du formulaire et Ikiform refuse les envois qui ne la respectent pas avec 422 validation_failed.

Le honeypot

Un honeypot est un input que les personnes ne voient jamais et que les bots remplissent. S'il a une valeur, l'envoi vient d'un logiciel. Il ne coûte rien aux visiteurs et attrape les bots les plus anciens et les plus courants, ceux qui analysent le HTML et remplissent chaque input trouvé.

Bien le masquer compte plus que l'astuce elle-même. Trois choses tournent mal avec un honeypot fait à la légère :

  • Les lecteurs d'écran l'annoncent. Un visiteur aveugle entend un champ de plus, le remplit, et se retrouve marqué comme spam. Englobez-le dans aria-hidden="true" et donnez-lui un label qui demande de le laisser vide.
  • Le clavier s'y arrête. Parcourir le formulaire avec Tab s'arrête sur un input invisible. tabindex="-1" le retire de l'ordre de tabulation.
  • Le remplissage automatique le remplit. Les navigateurs et les gestionnaires de mots de passe remplissent les champs selon leur nom. Appelez le champ email2 ou phone et certains le rempliront pour de vraies personnes. Utilisez un nom qu'aucun remplissage automatique ne reconnaît, comme _gotcha, et ajoutez autocomplete="off".

Le guide du honeypot couvre les techniques pour le masquer, la façon dont les bots les repèrent, et la vérification côté serveur pour chaque stack. Avec Ikiform, un honeypot rempli ajoute 5 au score, ce qui atteint à lui seul le seuil de 5. Vous pouvez renommer le champ pour chaque formulaire sous Honeypot field.

Le délai

Une personne met des secondes à remplir un formulaire de contact. Beaucoup de bots mettent des millisecondes. Un piège temporel enregistre le moment où le formulaire a été rendu et vérifie l'écart à l'envoi. La version naïve place un horodatage dans un champ masqué :

Piège temporel, la version naïve
const started = Number(formData.get("started"));
const seconds = (Date.now() - started) / 1000;
const tooFast = !Number.isFinite(seconds) || seconds < 3;

Un bot peut envoyer le nombre qu'il veut : un simple horodatage n'arrête donc que les bots qui ne s'en donnent pas la peine. Signez-le sur le serveur avec un secret, et le bot ne peut plus simuler un rendu plus ancien. La page sur arrêter le spam sans captcha construit la version signée.

Ikiform signe les heures de rendu pour vous quand le formulaire vient du SDK ou du composant shadcn/ui : ils envoient _ikiform_ts, et un envoi fait moins de 2 secondes après le rendu ajoute 3 au score. Un horodatage falsifié ou vieux d'un jour ajoute 3. Les formulaires HTML simples n'en envoient pas et ne sont pas pénalisés.

Le score du contenu

Une partie du spam est tapée ou collée par des personnes : elle passe donc toutes les vérifications anti-bot. Ce qui la trahit, c'est le contenu : liens, formules commerciales, adresses jetables et le même texte envoyé deux fois. Attribuez un score à chaque signal et traitez un total élevé comme du spam, plutôt que de bloquer sur un seul. Un lien dans un message est normal ; un lien dans le champ du nom ne l'est jamais.

SignalIkiform ajoute
Le honeypot est rempli+5
Un lien dans un champ de nom ou d'objet+3
Les mêmes champs envoyés à ce formulaire dans les dernières 24 heures+3
Envoyé moins de 2 secondes après l'heure de rendu signée+3
Trois liens ou plus sur l'ensemble des champs+2
L'une des 22 formules de spam connues, comme « seo services »+2
Une adresse sur un domaine d'e-mail jetable+2

À 5 ou plus, l'envoi est du spam. Aucun signal faible n'y arrive seul : un vrai message avec trois liens obtient 2. Deux ensemble y arrivent souvent, comme un lien dans le nom et une formule de spam. Si vous notez le contenu vous-même, Akismet est l'option hébergée de longue date ; beaucoup d'équipes commencent par quelques expressions régulières comme celles ci-dessus.

Une vérification humaine

Une vérification humaine demande au navigateur de prouver qu'une personne le pilote. Les modernes, comme Cloudflare Turnstile, tournent surtout de façon invisible et n'affichent une case à cocher qu'en cas de doute. Le widget donne un token au navigateur ; votre serveur doit envoyer ce token au fournisseur pour le vérifier. Un token jamais vérifié sur un serveur n'arrête rien, car un bot peut ignorer le widget et envoyer sans lui.

Ikiform propose trois réglages sous Spam check sur chaque formulaire :

RéglageCe qui se passeChangements de code
Off (the default)Aucun défi. Le honeypot, le délai et le score s'exécutent toujours.Aucune
IkiformTurnstile exécuté par Ikiform sur ikiform.com, sans compte ni clés CloudflareAucun pour les envois HTML. Les envois fetch appellent d'abord challenge() de @ikiform/sdk
Your own Turnstile keys (vos propres clés Turnstile)Votre widget et votre clé secrète. Ikiform vérifie le token et compare son hostname à vos domaines autorisésAffichez le widget dans votre formulaire pour qu'il envoie cf-turnstile-response

Un envoi fetch sans token reçoit 403 challenge_required. Si Cloudflare est injoignable, Ikiform garde l'envoi et le stocke comme spam avec la raison captcha_unavailable : vous pouvez donc le restaurer. La documentation sur le spam montre les deux parcours. Si vous hésitez entre Turnstile et reCAPTCHA de Google ou hCaptcha, voyez les alternatives à reCAPTCHA.

Limites de débit et domaines autorisés

Une limite de débit plafonne la fréquence à laquelle un visiteur peut envoyer. Elle ne distingue pas le spam du courrier légitime ; elle arrête le volume. Comptez par IP et par formulaire, autorisez une petite rafale, et répondez 429 avec un en-tête Retry-After. Le guide sur la limitation de débit en construit une pour chaque stack et explique pourquoi un compteur en mémoire échoue sur les hébergeurs serverless.

Ikiform compte chaque envoi précisément, avant de lire le corps. Chaque formulaire choisit un préréglage : Standard, 5 par minute par visiteur, Relaxed, 20 par minute par visiteur, ou Strict, 2 toutes les 10 minutes par visiteur. Standard autorise aussi au plus 3 envois toutes les 10 secondes, et le formulaire entier en accepte 300 par minute. Strict convient à un formulaire de contact, puisque personne d'honnête n'écrit deux fois en dix minutes. Les chiffres sont sur Limites de débit.

Allowed domains liste les sites où vit votre formulaire. Un envoi depuis toute autre page est marqué comme spam, ou refusé avec 403 origin_not_allowed si vous choisissez Reject. Cela empêche des tiers de faire pointer leurs propres formulaires vers votre endpoint. Un script déterminé peut falsifier l'en-tête vérifié : traitez donc cela comme une couche, pas comme un verrou.

Ce qu'il advient du spam

Ne dites jamais à un bot qu'il a été attrapé. Une erreur lui apprend quoi changer ; une page de succès normale ne lui apprend rien. Et ne supprimez jamais le spam à l'arrivée : tout filtre attrape un vrai message de temps en temps, et un message supprimé est perdu.

Un envoi jugé comme spam reçoit la même réponse de succès qu'un vrai : un bot n'apprend donc rien. Il est stocké avec le statut spam, n'envoie ni e-mail de notification ni webhook, ne compte pas dans votre consommation, et est supprimé au bout de 30 jours. Chaque lundi, un espace de travail qui a bloqué du spam reçoit un e-mail récapitulatif avec le total, les formulaires les plus sollicités et les principales raisons.

Ouvrez le filtre de statut du tableau de bord et choisissez Spam pour voir chaque envoi avec son score et ses raisons. Not spam le remet en place, et ses e-mails et webhooks partent alors. Désactivez l'e-mail du lundi sous Weekly spam summary dans les réglages de l'espace de travail. Le spam est conservé 30 jours : vérifiez donc au moins une fois par mois.

Si un vrai message se fait attraper à chaque fois, lisez ses raisons. Un lien dans un champ appelé business_name compte comme un lien dans un nom ; renommez le champ en business et il n'est plus considéré comme un champ de nom.

Choisissez votre cas

Chacune de ces pages approfondit une défense ou un type de site, avec du code pour ce cas.

Vérifiez que tout fonctionne

Faites ces tests sur un formulaire de test avant de vous y fier. Ikiform n'a pas d'offre gratuite. Les tests sont gratuits : un espace de travail sans offre accepte 50 soumissions de test par mois depuis localhost. Pour passer en production, choisissez Pro à partir de 6 $/mois pour 500 soumissions, ou payez une seule fois : 10 000 soumissions pour 49 $ ou 50 000 soumissions pour 149 $, avec des crédits qui n'expirent jamais. Voir les tarifs.

  1. Dans Allowed domains du formulaire, ajoutez le domaine de votre site, plus localhost pendant le développement. Laissez vide pour accepter les envois de partout.
  2. Remplissez le formulaire sur votre page et envoyez-le. Vous arrivez sur votre page de remerciement, ou sur celle hébergée par Ikiform.
  3. Ouvrez Submissions dans le tableau de bord. La nouvelle soumission y est, avec tous les champs envoyés.
  4. Envoyez avec le honeypot rempli, _gotcha=bot. L'envoi reçoit quand même une réponse de succès, mais la soumission est stockée comme spam et n'envoie ni e-mail ni webhook.
  5. Envoyez un message avec un lien dans le champ du nom et la formule seo services dans le message. Il est stocké comme spam avec les raisons url_in_name et keyword.
  6. Réglez Spam check sur Ikiform et envoyez le formulaire HTML simple. La page de vérification s'affiche un instant, puis votre page de remerciement.
  7. Envoyez le formulaire plusieurs fois de suite. Au-delà de la limite, le formulaire répond 429 et le visiteur voit la page de ralentissement d'Ikiform.
  8. Rien n'est arrivé ? Passez le filtre de statut du tableau de bord sur Spam. Le spam reçoit la même réponse de succès qu'une vraie soumission.

Dépannage

ProblèmeQue faire
La soumission est dans le tableau de bord mais aucun e-mail ni webhook n'est arrivéElle a été stockée comme spam. Le spam n'envoie rien. Ouvrez-la sous le filtre Spam pour voir les raisons, et marquez-la comme non-spam pour envoyer son e-mail et ses webhooks.
403 challenge_requiredLe spam check du formulaire est réglé sur Ikiform et un envoi fetch n'avait pas de jeton. Obtenez-en un avec challenge(formId) de @ikiform/sdk avant chaque envoi, ou désactivez la vérification.
403 origin_not_allowed, ou tous les envois finissent en spamLe domaine de la page n'est pas dans les Allowed domains du formulaire. Ajoutez-le, plus localhost pour les tests en local. Les sous-domaines d'un domaine listé sont autorisés.
429 rate_limitedUn visiteur a envoyé plus que ce que permet la limite de débit du formulaire. Standard autorise 5 envois par minute et par visiteur. Attendez la durée de Retry-After, ou choisissez Relaxed ou Custom pour les formulaires qui envoient depuis une seule IP partagée.
403 captcha_failedLe token Turnstile était absent, expiré ou utilisé deux fois. Un token vit 300 secondes et ne sert qu'une fois : affichez donc un nouveau widget, ou rappelez challenge(), après chaque tentative.
Le spam arrive toujours comme reçuOuvrez-en un et voyez ce qu'il a en commun avec les autres. Le spam scripté demande de régler Spam check sur Ikiform ; les démarchages tapés à la main demandent une limite de débit plus stricte et une relecture hebdomadaire.
De vrais visiteurs disent ne pas pouvoir envoyerVérifiez que le honeypot est masqué aux lecteurs d'écran et nommé de façon à ce que le remplissage automatique l'ignore, et qu'une limite de débit stricte n'attrape pas des personnes derrière l'IP d'un même bureau.

Questions

Une étape vous bloque, ou vous voulez un guide pour votre cas ? Écrivez à hello@ikiform.com.