Il y a quelque chose d'un peu injuste dans la façon dont on parle des sites faits avec l'aide d'une intelligence artificielle. On les regarde de haut, on ironise sur le résultat et pendant ce temps, des milliers de personnes ont mis leur activité en ligne en un week-end, sans budget, avec un résultat qui fonctionne.
Autant le dire franchement : c'est une bonne nouvelle, et la critique de façade n'a aucun intérêt. Mettre un site en ligne était déjà accessible avant ; c'est simplement devenu rapide. Cette étape a toujours été la partie visible du travail, et la moins risquée.
Le problème est ailleurs, et il est réel : l'IA a résolu la construction, pas l'exploitation. Un site n'est pas un livrable qu'on rend une fois, c'est un service en fonctionnement. Le jour de la mise en ligne, il est à jour. Quelques mois plus tard, sans que personne y ait touché, il ne l'est plus parce que ce sont les correctifs publiés entre-temps qui ont bougé, pas votre site.
Voici, très concrètement, ce que nous trouvons en reprenant ces sites.
1. Des clés d'accès laissées côté navigateur
C'est de très loin le cas le plus fréquent, et le plus coûteux.
Pour envoyer un e-mail, interroger une base ou appeler un service d'intelligence artificielle, votre site utilise une clé. Cette clé doit rester sur le serveur. Or quand le code est écrit d'un seul jet, elle se retrouve souvent dans la partie envoyée au navigateur donc visible par n'importe qui affichant le code source de la page.
Les conséquences sont immédiates : le service est consommé à votre place, et la facture est pour vous. Sur un service facturé à l'usage, la découverte se fait généralement en fin de mois.
Le test prend trente secondes : affichez le code source de votre page et cherchez key, token, secret ou api. Si vous tombez sur une longue suite de caractères aléatoires, elle est publique.
2. Une base de données restée grande ouverte
Les bases de données prêtes à l'emploi accélèrent énormément le développement. Elles ont toutes le même défaut : pour ne pas bloquer pendant la construction, les règles d'accès sont permissives par défaut.
Elles sont censées être refermées avant la mise en ligne. Elles ne le sont presque jamais, parce que rien ne le rappelle : le site fonctionne exactement pareil, ouvert ou fermé. La différence n'apparaît que le jour où quelqu'un lit votre table de clients depuis l'extérieur.
3. Aucun garde-fou sur les formulaires
Un formulaire sans limitation d'envoi est une invitation. Les robots trouvent l'adresse en quelques jours et s'installent : messages en série, inscriptions factices, boîte de réception inutilisable.
Le cas le plus douloureux est celui où le formulaire déclenche quelque chose de facturé un envoi d'e-mail, un appel à un service d'IA. Là, chaque soumission automatisée coûte de l'argent, et l'addition grimpe toute seule pendant que vous dormez.
4. Des dépendances qui vieillissent en silence
Un site moderne repose sur des centaines de bibliothèques écrites par d'autres. Elles reçoivent des correctifs de sécurité en permanence : c'est le fonctionnement normal et sain de l'écosystème.
Sauf que personne ne les applique. Et surtout, rien ne prévient : aucun symptôme, aucune alerte, le site continue de s'afficher parfaitement. Il vieillit simplement, jusqu'au jour où une faille connue depuis des mois est exploitée automatiquement.
C'est exactement le mécanisme que nous avons documenté sur la faille WordPress wp2shell : les correctifs étaient publics, les premières attaques automatisées sont arrivées le lendemain.
5. Personne ne sait où c'est déployé
Celle-là ne relève pas de la sécurité, mais elle finit toujours par coûter le plus cher.
Où le site est-il hébergé ? Qui détient les accès ? Le nom de domaine est-il à votre nom ou à celui d'un compte personnel ? Existe-t-il une sauvegarde, et a-t-elle déjà été restaurée pour vérifier qu'elle fonctionne ?
Quand un site est construit seul et vite, ces réponses vivent dans la tête d'une seule personne. Le jour où cette personne n'est plus disponible, plus rien n'est modifiable, et rien n'est récupérable.
Ce que dit la loi si vos données fuient
C'est le point que presque personne n'anticipe.
Si votre formulaire de contact, votre liste d'inscrits ou votre fichier client a pu être consulté, il s'agit d'une violation de données à caractère personnel. Vous avez alors l'obligation de la notifier à la CNIL dans un délai de 72 heures, et d'informer les personnes concernées lorsque le risque pour elles est élevé.
Ce n'est pas un argument commercial, c'est le règlement européen sur la protection des données. Et aucun générateur de site ne s'en occupe à votre place : l'obligation pèse sur vous, en tant que responsable du traitement.
Six vérifications à faire aujourd'hui
Aucune ne demande de compétence technique particulière :
- Affichez le code source de votre page d'accueil et cherchez
key,token,secret,api. - Vérifiez le nom de domaine : est-il enregistré à votre nom, avec un renouvellement automatique actif ?
- Cherchez la sauvegarde. Si vous ne savez pas où elle est, elle n'existe pas.
- Regardez la date du certificat dans la barre d'adresse du navigateur : quand expire-t-il, et qui le renouvelle ?
- Testez votre domaine contre l'usurpation d'e-mail avec notre outil SPF et DMARC un domaine sans DMARC peut être utilisé pour envoyer des messages frauduleux en votre nom.
- Si c'est un WordPress, vérifiez sa version : une version en retard est le premier vecteur d'intrusion.
Ce qu'il faut retenir
- Construire un site est devenu rapide, et c'est très bien ainsi.
- Ce qui n'a pas changé, c'est l'après : correctifs, surveillance, sauvegardes, accès.
- Dans la grande majorité des cas, il n'y a rien à refaire il y a à reprendre en main.
Si vous avez fait votre site vous-même et que ces six points vous laissent dans le doute, c'est exactement ce que couvre notre maintenance de site web : état des lieux, correction de l'urgent, puis surveillance et sauvegardes vérifiées. Sans juger la façon dont il a été construit.
Un site qu'on ne surveille pas n'est pas un site terminé. C'est un site en attente d'incident.