# Ce qui reste actif d’une expérimentation IA que plus personne ne suit

> Clés d'API oubliées, webhooks morts, appels de test jamais retirés : ce qu'on retrouve sur un site après l'abandon d'un essai d'intégration IA.

- Auteur : WordPress Développement
- Publié le : 2024-03-21
- Mis à jour le : 2024-03-21
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/experimentation-ia-abandonnee-cles-actives/

## L’essentiel

- Une clé d'API oubliée reste une porte ouverte tant qu'elle n'est pas révoquée
- Un webhook mort continue de recevoir des données sans qu'on le sache
- Retirer une intégration demande plus de rigueur que l'installer

Une clé d'API valide, un webhook qui répond encore, un shortcode qui déclenche un appel vers un service tiers : voilà ce qu'on retrouve, mois après mois, sur des sites où une expérimentation d'intégration IA a été lancée puis abandonnée sans être proprement démontée.

Le scénario se répète avec une régularité frappante. Une équipe teste un service de génération de texte ou de modération automatique, le projet ne convainc pas ou change de priorité, et le code reste en place — actif, fonctionnel, mais sans surveillance. Ce n'est pas un bug : c'est une extension qui continue de faire exactement ce pour quoi elle a été programmée, sans que personne ne s'en souvienne.

## L'inventaire d'un abandon typique

Sur les audits que nous avons menés, le motif se répète : une clé stockée dans les options de WordPress via `update_option()`, jamais chiffrée, jamais retirée après la fin du test. Un cron WP planifié pour appeler un service externe toutes les heures, qui continue de tourner et de consommer des jetons pour un traitement dont plus personne ne lit le résultat.

On trouve aussi des routes REST personnalisées, enregistrées via `register_rest_route()`, qui exposaient un point d'entrée pour recevoir la réponse d'un service de modération et qui répondent toujours aux requêtes entrantes, des mois après que le prestataire ayant configuré le service a quitté le projet.

## Pourquoi c'est un problème de sécurité, pas seulement de propreté

> L'essentiel à retenir : Une clé d'API oubliée reste une porte ouverte tant qu'elle n'est pas révoquée ; Un webhook mort continue de recevoir des données sans qu'on le sache ; Retirer une intégration demande plus de rigueur que l'installer

Une clé d'API active représente un accès facturable et parfois un accès aux données du site. Si le service tiers est compromis, ou si la clé fuite dans un dépôt de code, l'attaquant hérite d'un accès que personne ne surveille plus. Un webhook oublié, lui, accepte des requêtes entrantes sans validation stricte de leur origine, ce qui en fait une cible pour des tentatives d'injection ou de saturation.

- Une clé active facture même si le service n'est plus utilisé volontairement
- Un webhook oublié reste une surface d'attaque non surveillée
- Un cron mort consomme des ressources serveur sans aucune valeur en retour
- Personne ne reçoit d'alerte quand ces éléments dérivent ou échouent silencieusement

## Comment les repérer méthodiquement

La méthode la plus fiable reste l'inventaire croisé entre trois sources : les options de la base de données contenant des motifs comme `_api_key` ou `_token`, les tâches planifiées visibles via `wp cron event list`, et les routes REST personnalisées listées par `rest_api_init`. Un site qui n'a jamais eu de projet IA documenté ne devrait présenter aucune de ces traces.

```
wp option list --search="*api_key*" --format=table
wp cron event list --fields=hook,next_run_gmt
wp eval 'print_r( rest_get_server()->get_routes() );'
```

Ces trois commandes suffisent à dresser un premier état des lieux. Sur un site où nous avons retrouvé une clé de service de génération d'images restée active dix-huit mois après l'arrêt du projet, ce croisement a permis de la localiser en moins d'une heure, alors qu'une recherche manuelle dans le code n'avait rien donné.

## Retirer sans casser une intégration encore utile

Le piège inverse existe aussi : supprimer une clé ou un cron qui sert encore, discrètement, à une fonctionnalité dont personne ne connaît plus l'origine. Avant toute suppression, il faut vérifier les journaux d'appels sur les trente derniers jours plutôt que de couper à l'aveugle.

> Sur nos projets, la règle est de désactiver avant de supprimer : on coupe l'appel sortant, on observe une semaine, puis seulement on retire le code et on révoque la clé côté fournisseur.

## Documenter pour que ça ne se reproduise pas

Chaque intégration IA mériterait une fiche courte, tenue à jour, indiquant sa date de mise en service, son responsable, et surtout la procédure de retrait prévue si le projet est abandonné. Sans cette trace, le retrait dépend uniquement de la mémoire de la personne qui a configuré l'intégration — une ressource qui finit toujours par disparaître.

## En résumé

Une expérimentation IA abandonnée ne s'efface jamais toute seule : elle continue de tourner, de facturer et d'exposer une surface d'attaque tant que personne ne la retire explicitement. L'audit régulier des clés, des crons et des routes REST reste le seul moyen fiable de repérer ces résidus avant qu'ils ne deviennent un incident.