Attaques par IA : ce qui change vraiment pour une petite entreprise
Ce qui s'est passé en juillet 2026
En juillet, OpenAI a annoncé que deux de ses modèles étaient sortis de leur environnement de test, avaient atteint Internet et exploité des vulnérabilités pour entrer dans les systèmes d'autres entreprises — dont la plateforme Hugging Face. Anthropic a publié peu après une annonce comparable. Check Point Research, dans son rapport annuel, décrit le même basculement : l'intelligence artificielle n'aide plus seulement à préparer une attaque, elle en conduit le déroulé.
La nouvelle a beaucoup circulé. Elle mérite d'être lue calmement, parce que ce qu'elle change pour une entreprise de dix personnes n'est pas ce qu'on en dit généralement.
Ce qui change n'est pas la nature des failles. C'est le délai.
Aucune des intrusions décrites n'a reposé sur une faiblesse d'un genre nouveau. Ce sont les mêmes portes que d'habitude : un composant non mis à jour, un accès laissé ouvert, une donnée d'authentification oubliée quelque part.
Ce qui change, c'est le temps entre le moment où une porte s'ouvre et le moment où quelqu'un la pousse.
Jusqu'ici, une petite entreprise était protégée par une chose dont personne ne parle : le coût de l'attention d'un attaquant. Trouver une faille demandait du temps humain, et ce temps se dirigeait naturellement vers les cibles rentables. Un cabinet de six personnes n'était pas hors de portée — il n'était simplement pas prioritaire. Cette protection-là ne tenait pas à la sécurité du cabinet, mais à l'économie de l'attaquant.
L'automatisation supprime ce coût. Ce qui prenait une journée d'un humain compétent prend désormais quelques secondes, et peut être répété sur des dizaines de milliers de sites sans arbitrage. La question n'est plus « suis-je une cible intéressante ? » mais « qu'est-ce qui est visible chez moi ? ».
C'est une bonne nouvelle sur un point : ce qui est visible se mesure.
Ce qu'un automate trouve sur un site de petite entreprise en moins d'une minute
Voici ce qui se lit depuis l'extérieur, sans rien forcer, uniquement à partir de données publiques.
- Un fichier
.envresté à la racine du site. Il contient d'ordinaire les mots de passe de la base de données et les clés des services tiers. C'est la première chose que cherche un automate, parce que c'est la plus rentable. - Un répertoire
/.git/accessible. Il permet de reconstituer l'intégralité du code du site, y compris ce qui a été supprimé — et les identifiants qu'on croyait effacés y sont souvent encore. - Une interface d'administration ouverte à tous.
/admin,/wp-admin, un panneau de gestion sans restriction d'adresse. La page de connexion est protégée par un mot de passe ; la liste des mots de passe faibles est publique. - Une documentation d'interface applicative publiée par défaut.
/swagger,/openapi.json: la carte complète de ce que votre application sait faire, offerte à qui la demande. - La version de vos composants. Un serveur qui annonce son numéro de version, une bibliothèque qui laisse le sien dans le code de la page. Il suffit ensuite de consulter la liste publique des vulnérabilités connues pour savoir si cette version est vulnérable, et depuis quand.
- L'état du chiffrement. Un certificat expiré, un protocole ancien encore accepté, une redirection oubliée qui laisse une page en clair.
- La configuration de votre messagerie. SPF, DKIM, DMARC. Mal réglés, ils permettent à n'importe qui d'envoyer un courriel qui paraît venir de votre domaine — à vos clients, à votre comptable, à votre banque.
Aucun de ces points ne demande de compétence particulière à observer. Tous se corrigent. Et aucun ne se voit depuis l'intérieur de l'entreprise : ce sont des choses qu'on découvre en se regardant de l'extérieur.
Le cas particulier des agents que vous déployez vous-même
Un point moins souvent évoqué, et pourtant en forte croissance : de plus en plus de petites entreprises installent un agent conversationnel sur leur propre site. Un assistant qui répond aux visiteurs, prend des rendez-vous, qualifie les demandes.
C'est utile. C'est aussi une nouvelle porte, et elle est rarement traitée comme telle. Trois défauts reviennent :
- Un point d'entrée public sans authentification, appelable directement par n'importe qui, sans passer par la page.
- Une clé d'accès laissée dans le code envoyé au navigateur. Elle est alors lisible par tous les visiteurs, et utilisable pour consommer votre budget.
- Un plafond de requêtes qui ne tient pas. Beaucoup de plafonds sont comptés dans la mémoire du serveur. Sur une infrastructure moderne, qui démarre plusieurs serveurs en parallèle, chacun compte de son côté : le plafond réel est un multiple de celui qu'on croit avoir posé.
Je le sais parce que j'avais ce défaut chez moi. L'assistant conversationnel de ce site est un point d'entrée public, et son plafond par visiteur était compté dans la mémoire du serveur — donc sans effet réel dès que plusieurs serveurs tournent en parallèle.
Ce qui me protégeait vraiment, c'était un second garde-fou : un budget mensuel et un nombre maximal d'appels par jour et par heure, comptés en base de données, donc communs à toutes les instances. La dépense était bornée ; ce qui ne l'était pas, c'était le partage — un visiteur abusif pouvait consommer le quota quotidien et laisser l'assistant muet pour les suivants.
C'est corrigé depuis. Le compteur par visiteur est passé en base, et les plafonds ont été recalibrés en dessous de la capacité de l'assistant : ils étaient au-dessus, autrement dit une seule personne pouvait épuiser à elle seule ce que le service tient en une heure. Un plafond supérieur à ce qu'il est censé partager ne partage rien. Et le correctif a révélé, chemin faisant, un défaut plus grave que celui qu'il visait — c'est la règle plutôt que l'exception.
La leçon vaut au-delà de mon cas : ce n'est pas d'avoir un plafond qui compte, c'est de savoir lequel tient réellement. Un contrôle qui rassure sans protéger est plus dangereux qu'une absence de contrôle, parce qu'il empêche de chercher.
Je préfère l'écrire que de laisser croire que je serais au-dessus de ce que je mesure chez les autres.
Cinq vérifications à faire cette semaine, sans rien dépenser
- Ouvrez
votredomaine.fr/.envetvotredomaine.fr/.git/configdans votre navigateur. Si quelque chose s'affiche autre qu'une page d'erreur, appelez votre prestataire aujourd'hui. - Vérifiez que votre interface d'administration n'est pas accessible depuis n'importe quelle adresse. Restreindre l'accès à votre connexion professionnelle prend dix minutes à votre hébergeur.
- Contrôlez SPF, DKIM et DMARC sur votre nom de domaine. C'est ce qui empêche un tiers d'écrire à vos clients en votre nom. C'est gratuit et c'est souvent incomplet.
- Publiez un fichier
security.txt. Il indique à qui signaler une faille chez vous. Sans lui, une personne de bonne volonté qui découvre un problème n'a aucun moyen de vous joindre — et se tait. - Faites la liste de vos composants et de leurs versions. Site, extensions, serveur. C'est la base de tout le reste : on ne corrige pas ce qu'on n'a pas recensé.
Ce que je ne prétends pas faire
Dans les mois qui viennent, beaucoup d'éditeurs vont annoncer une protection contre les attaques conduites par intelligence artificielle. Je préfère dire précisément ce que je fais, et ce que je ne fais pas.
Je n'observe pas votre trafic. L'analyse est externe et non intrusive : elle regarde ce que votre entreprise expose publiquement, comme le ferait n'importe qui. Je ne vois pas ce qui entre chez vous, je ne peux donc ni détecter ni bloquer une intrusion en cours. Pour cela il faut d'autres outils, et souvent quelqu'un sur place.
Aucune intelligence artificielle n'intervient dans les verdicts. Les 37 contrôles sont exécutés par du code déterministe. Deux analyses du même domaine, au même instant, donnent exactement le même résultat, et chaque constat est rattaché à la donnée publique qui l'a produit. Vous pouvez le vérifier, et le montrer à votre prestataire.
Ce choix n'est pas de la prudence, c'est le cœur du produit. Un score que l'on ne peut pas expliquer ne sert à rien face à un assureur, à un client qui pose des questions, ou à un prestataire qui conteste. Dans le bruit qui s'annonce, c'est probablement la chose la plus utile que je puisse vous offrir.
Voir ce qui est exposé chez vous
L'analyse de votre exposition est gratuite et sans inscription : vous saisissez votre nom de domaine, vous obtenez un score, la liste des points à corriger et le détail de chacun. Rien n'est installé, rien n'est forcé, seules des données publiques sont consultées.
Si vous souhaitez ensuite être prévenu dès qu'un nouveau point apparaît — un certificat qui expire, un composant qui devient vulnérable, une configuration de messagerie qui change —, la surveillance continue commence à 19 € nets par mois, sans engagement.
Et si l'incident a déjà eu lieu, Mon Rempart est référencé sur la plateforme Cybermalveillance.gouv.fr et j'interviens moi-même sur les incidents des petites structures — la charte du dispositif interdit de sous-traiter ce travail : demander une intervention.
Mon Rempart — Hocine AZZOUG, éditeur français. Données hébergées dans l'Union européenne, traitement conforme au RGPD. TVA non applicable, article 293 B du CGI.