Un formulaire de contact qui finit par recevoir plus de messages de robots que de vrais prospects, c'est un grand classique. La réponse habituelle a longtemps consisté à lui greffer un CAPTCHA externe. Quelques cases à cocher, parfois des photos de feux tricolores à identifier et, avec un peu de chance, moins de spam dans la boîte mail.
Avec Joomla 6.1, une autre approche est arrivée directement dans le cœur du CMS : un CAPTCHA fondé sur le Proof of Work, ou « preuve de travail ». Pas de compte fournisseur à créer, pas de clé API Google à renseigner, pas de jeu d'images à faire résoudre au visiteur. La promesse est séduisante, particulièrement pour ceux qui, comme moi, passent leur temps à chercher le meilleur compromis entre sécurité, accessibilité et simplicité de maintenance.
Peut-il remplacer Google reCAPTCHA sur tous les formulaires Joomla ? Regardons la technologie et les tests indispensables.
1. Joomla 6.1 remet un CAPTCHA dans le cœur du CMS
Lors du passage à Joomla 5, les plugins reCAPTCHA historiques ont disparu des nouvelles installations du cœur du CMS. Conserver cette protection exigeait donc une solution compatible, souvent tierce : une dépendance et une maintenance de plus.
Le 14 avril 2026, Joomla 6.1 a donc introduit un plugin natif nommé Proof-of-Work CAPTCHA. Le projet Joomla le présente comme une protection antispam qui fonctionne sans compte externe ni clé API, avec un mécanisme reposant sur la bibliothèque libre ALTCHA. Le plugin est intégré au CMS : il n'est pas nécessaire de souscrire au service hébergé ALTCHA pour utiliser cette fonction native.
Petite précision de calendrier : Joomla 6.2 est sorti le 13 octobre 2026. Nous parlons ici d'une fonctionnalité introduite dans Joomla 6.1 et toujours pertinente sur la branche 6.x ; pour un nouveau projet ou une mise à niveau, on examine la version maintenue la plus récente, pas une 6.1.0 figée en avril.
Le Proof of Work poursuit un autre objectif que les défis classiques : rendre chaque soumission assez coûteuse pour décourager les envois massifs.
2. Le Proof of Work : faire travailler la machine, pas le visiteur
Le principe est assez élégant. Quand une personne utilise un formulaire protégé, le serveur prépare un petit défi de calcul. Le navigateur réalise l'opération localement et transmet une preuve de résolution. Le serveur peut ensuite vérifier cette preuve avant d'accepter la soumission.
Pour un visiteur, le calcul se déroule en arrière-plan, sans passage piéton à reconnaître. Pour un programme envoyant des milliers de messages, chaque soumission entraîne du travail supplémentaire.
Ce que le système vérifie réellement
Il ne prouve pas que l'expéditeur est une personne. Un robot peut aussi résoudre un défi mathématique. Le mécanisme vise surtout à augmenter le coût des soumissions automatisées, ce qui peut rendre certaines campagnes de spam moins rentables. C'est une mesure de friction économique et technique, pas un détecteur infaillible d'intelligence humaine.
Pourquoi ALTCHA est intéressant dans Joomla
Cette bibliothèque open source utilisée localement évite une dépendance externe. Pour une agence qui maintient de nombreux sites, moins de comptes, de consoles et de clés API, c'est une simplification appréciable.
Une protection discrète améliore le parcours. Mais le calcul consomme tout de même des ressources dans le navigateur.
3. Proof of Work contre Google reCAPTCHA : qu'est-ce qui change ?
Comparons les caractéristiques plutôt que de décréter un gagnant : reCAPTCHA propose plusieurs versions, avec défis visuels ou analyse de risque.
| Critère | CAPTCHA Joomla Proof of Work | Google reCAPTCHA |
|---|---|---|
| Principe | Calcul exécuté dans le navigateur, puis vérifié | Analyse de risque et/ou défi utilisateur selon la version |
| Service externe | Pas nécessaire avec le plugin natif | Service Google utilisé |
| Compte et clés API | Non nécessaires pour le plugin natif | Clés/configuration du service nécessaires |
| Expérience visiteur | Calcul généralement discret | Variable selon la version et le niveau de risque |
| Coût côté navigateur | Travail de calcul explicite | Scripts et traitements propres au service |
| Protection | Freine les envois massifs ; ne distingue pas humain et robot | Évalue le risque ou propose un défi ; pas infaillible non plus |
| Compatibilité Joomla | À vérifier formulaire par formulaire | Dépend de l'extension ou de l'intégration installée |
La confidentialité : un vrai intérêt, mais pas un certificat RGPD
Google indique que reCAPTCHA utilise notamment un cookie technique _GRECAPTCHA pour son analyse de risque. Un dispositif externe demande donc d'examiner ses flux et sa configuration dans le cadre de la politique de confidentialité du site.
Le Proof of Work natif réduit cette dépendance, puisque le défi et sa vérification n'ont pas besoin d'un service Google. C'est intéressant pour la maîtrise des échanges de données. Attention toutefois : cela ne rend pas automatiquement un site conforme au RGPD. Le formulaire continue de traiter des données personnelles, les journaux serveur peuvent conserver des adresses IP et le reste du site possède peut-être d'autres traceurs. Le sujet doit être regardé dans son ensemble.
L'accessibilité : moins d'obstacles, mais toujours des contrôles
Éviter de demander à quelqu'un de déchiffrer une image est une bonne nouvelle. Joomla présente le Proof of Work comme accessible, et cette approche supprime effectivement le type de défi visuel qui peut gêner certains utilisateurs. Pour autant, il faut vérifier le parcours avec un clavier, un lecteur d'écran, des messages d'erreur clairs et des appareils peu puissants. L'accessibilité concerne le formulaire complet, pas seulement son CAPTCHA.
4. Ce que le CAPTCHA Proof of Work ne résout pas
Un bon choix d'architecture commence aussi par les limites. Je vois au moins quatre points à surveiller avant de remplacer une protection existante.
Un robot motivé peut quand même envoyer du spam
Un programme automatisé peut calculer les défis. Un attaquant disposant de ressources informatiques importantes peut donc contourner la barrière économique que constitue le Proof of Work. Le dispositif peut réduire certaines campagnes, pas supprimer définitivement les messages indésirables ni protéger à lui seul contre une attaque ciblée.
Le téléphone ancien n'a pas la puissance d'un poste de travail
La preuve se calcule dans le navigateur. Sur un appareil lent, en mode économie d'énergie ou dans certaines conditions, elle peut demander davantage de temps. Il faut mesurer ce comportement sur des mobiles représentatifs, pas seulement depuis l'ordinateur du développeur branché sur une connexion rapide.
JavaScript et HTTPS restent des prérequis à contrôler
ALTCHA s'appuie sur des fonctions cryptographiques du navigateur qui requièrent un contexte sécurisé, généralement HTTPS, ainsi que JavaScript. Cela appelle des tests spécifiques pour les personnes dont le navigateur bloque les scripts, pour les politiques de sécurité du contenu (CSP) et pour les erreurs réseau. Le comportement exact dépend de l'intégration du plugin et du formulaire.
Une extension de formulaire n'utilise pas forcément le CAPTCHA global
Contact natif, constructeur de formulaires, newsletter et e-commerce n'utilisent pas forcément la même intégration. Activer le plugin ne prouve pas que tous les formulaires sont protégés.
Je conserve donc les autres couches de défense : validation serveur, contrôle des pièces jointes, limitation de fréquence ou règles WAF adaptées, surveillance des journaux et maintenance du CMS. Nous avons détaillé cette logique dans notre article sur la sécurisation d'un site Joomla.
5. Comment activer le CAPTCHA natif de Joomla 6.1 et versions suivantes ?
Le principe de configuration publié par Joomla est simple. Sur une installation Joomla 6.x à jour :
- Ouvrir l'administration et rechercher les plugins.
- Filtrer les plugins sur le terme CAPTCHA.
- Repérer et activer le plugin Proof-of-Work CAPTCHA.
- Dans la configuration globale, choisir ce CAPTCHA comme option par défaut lorsque le réglage est proposé.
- Configurer un formulaire de contact natif, puis vérifier sa soumission réelle.
Les intitulés varient selon la langue. Le réglage global ne dispense pas de vérifier chaque composant et les extensions qui gèrent leur propre protection.
J'insiste sur la version de Joomla : le correctif 6.1.4, publié le 29 septembre, mentionne notamment une modification concernant le contrôle CSRF du CAPTCHA Proof of Work. Ce n'est pas une raison de paniquer ; c'est une raison supplémentaire de tester sur une version 6.x maintenue et mise à jour, aujourd'hui Joomla 6.2, et d'éviter les installations anciennes abandonnées.
Si vous partez de Joomla 5, on ne lance pas une montée de version seulement pour ajouter un CAPTCHA. On vérifie d'abord le thème, les extensions, la version de PHP, la sauvegarde et la procédure de retour arrière. Une copie de préproduction reste le meilleur endroit pour faire les premiers essais.
6. Avant la production : la grille de tests que je recommande
La fiche de fonctionnalité de Joomla est une chose ; le comportement sur votre site en est une autre. Je n'ai pas de statistiques de blocage à vous annoncer pour TooNetCreation à ce stade. Voici plutôt les vérifications que je demanderais à l'équipe de réaliser avant de valider une bascule.
| Scénario | Ce qu'il faut vérifier |
|---|---|
| Soumission normale | Message accepté une seule fois et notification bien reçue |
| Champs invalides | Erreurs lisibles, données conservées si possible, pas de blocage inutile |
| Rafraîchissement et retour navigateur | Absence de réutilisation problématique d'une preuve ou de double envoi |
| Mobile ancien / CPU limité | Délai de résolution, fluidité, consommation de ressources |
| Clavier et lecteur d'écran | Parcours complet, focus, libellés et annonce des erreurs |
| JavaScript bloqué / CSP restrictive | Comportement explicite et absence de soumission silencieusement perdue |
| Formulaires tiers et modules | Protection effectivement exécutée et vérifiée côté serveur |
| Envois répétés contrôlés | Résistance du dispositif et journalisation, sans test de charge agressif |
Sur un projet e-commerce, j'ajouterais un test des formulaires liés au compte client, aux demandes de devis et au service après-vente. Chaque formulaire possède sa propre valeur métier. Une protection antispam qui bloque un client légitime peut coûter bien plus cher que les quelques messages indésirables qu'elle évite.
Comment juger si le remplacement fonctionne ?
On peut relever avant et après changement : le nombre de spams reçus, les soumissions légitimes, les erreurs techniques, le temps nécessaire pour envoyer un formulaire et les signalements des utilisateurs. Il faut comparer sur une durée suffisante, avec des conditions proches, et tenir compte des autres modifications du site. Un test sur une seule journée ne suffit pas.
Un suivi de performance sur mobile a aussi sa place, en complément des mesures habituelles de chargement. L'objectif n'est pas d'obtenir un score flatteur pour la galerie : c'est de vérifier qu'une personne peut réellement nous écrire, y compris depuis un téléphone modeste.
7. Alors, faut-il remplacer Google reCAPTCHA par le CAPTCHA Joomla ?
Pour un site vitrine Joomla avec un formulaire natif et un volume de spam modéré, je considère le Proof of Work comme une option très sérieuse. Il permet de réduire la dépendance à un fournisseur externe, de simplifier l'administration et d'éviter les défis visuels traditionnels. Sur ce type de site, je commencerais volontiers par un essai encadré.
Pour un portail fortement sollicité, une application qui subit des attaques ciblées ou un site utilisant plusieurs extensions métier, la réponse demande davantage d'analyse. Une solution de type reCAPTCHA peut fournir d'autres mécanismes de détection de risque ; à l'inverse, elle introduit ses propres contraintes d'intégration. Il n'existe pas de remplacement universel sans examen du contexte.
Ma décision dépendrait principalement de cinq questions :
- Quels formulaires doivent être protégés, et lesquels utilisent réellement l'API CAPTCHA de Joomla ?
- Quel type de spam reçoit-on : envois simples automatisés, attaques massives, messages ciblés ?
- Quelle population utilise le site, notamment sur mobile ou avec des technologies d'assistance ?
- Dispose-t-on de mesures avant changement pour évaluer le résultat ?
- Quel sera le coût de maintenance de la solution dans deux ans ?
Sur une Web Factory ou un parc multisite, je privilégie des composants documentés, des configurations homogènes et une recette reproductible. Une protection que personne ne sait maintenir devient vite une dette technique.
Chez TooNetCreation, nous pouvons auditer ces points et les intégrer dans un plan de protection plus large, notamment avec un WAF pour les sites exposés. Le CAPTCHA n'est qu'une pièce du puzzle, même si c'est celle que l'utilisateur remarque le plus.
8. Questions fréquentes sur le CAPTCHA Proof of Work de Joomla
Le CAPTCHA Proof of Work est-il inclus gratuitement dans Joomla 6.1 ?
Oui. Joomla 6.1 introduit un plugin natif basé sur un mécanisme open source. L'utilisation du plugin ne nécessite pas de compte ni de clé API d'un service CAPTCHA tiers.
Peut-on l'utiliser sans JavaScript ?
La bibliothèque ALTCHA utilisée repose sur l'exécution de calculs dans le navigateur, avec JavaScript et un contexte sécurisé. Il faut donc tester et prévoir clairement le comportement des formulaires lorsque ces conditions ne sont pas réunies.
Le Proof of Work rend-il un site conforme au RGPD ?
Non, pas à lui seul. Il supprime une dépendance externe pour le CAPTCHA natif, mais les autres traitements du formulaire, les journaux, les traceurs et la politique de conservation restent à examiner.
Est-il compatible avec tous les formulaires Joomla ?
Ce n'est pas une hypothèse à faire. Le fonctionnement doit être vérifié pour chaque extension ou formulaire personnalisé, particulièrement si le composant gère son propre CAPTCHA.
Un progrès utile, à valider sur chaque site
Je trouve cette évolution de Joomla bienvenue. Après des années à intégrer des protections externes, retrouver un CAPTCHA natif, autonome et fondé sur un autre principe que le test visuel est une avancée concrète. Ce n'est pas la disparition du spam ; c'est une option supplémentaire, particulièrement cohérente avec l'esprit open source.
Mon conseil est simple : testez le Proof of Work sur un formulaire représentatif, mesurez son comportement, puis élargissez si le résultat est bon. Et gardez les autres protections en place. Le meilleur CAPTCHA est celui qui complique la vie des robots sans compliquer celle de vos visiteurs.
Vous maintenez un site Joomla et vous hésitez sur les protections, les extensions ou une mise à niveau vers Joomla 6 ? Échangeons sur votre architecture avec TooNetCreation. Un contrôle ciblé vaut mieux qu'un changement de plugin au hasard.
Sources techniques
- Joomla Project : annonce officielle de Joomla 6.1, 14 avril 2026.
- Joomla Project : annonce officielle de Joomla 6.2, 13 octobre 2026.
- David Jardin, Joomla Community Magazine : présentation du CAPTCHA natif, janvier 2026.
- Joomla Issue Tracker : intégration du CAPTCHA Proof of Work, PR #46514.
- Joomla 6.1.4 : notes de correctifs, septembre 2026.
- Documentation ALTCHA : intégration et exigences techniques.
- Google : FAQ technique reCAPTCHA.
