# Extension IA prête pour la production : la checklist complète > Clés, limites, repli, journalisation, coûts, consentement, tests : la liste complète que nous cochons avant de livrer une extension IA à un client. - Auteur : Clément Hadrot - Publié le : 2026-05-04 - Mis à jour le : 2026-05-04 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/extension-ia-production-checklist/ ## L’essentiel - Neuf familles de vérifications avant toute livraison client - Le consentement utilisateur se traite en amont, pas après coup - Un test de charge sur l'appel IA évite la mauvaise surprise du lancement Après plusieurs livraisons d'extensions intégrant de l'IA, notre équipe a fini par formaliser une checklist unique, désormais obligatoire avant toute mise en production. Elle ne remplace pas les tests fonctionnels classiques, mais couvre les points spécifiques à une fonctionnalité IA que l'on oublie encore trop souvent sous la pression d'un délai serré. Cet article ne traite pas des agents autonomes capables d'agir sans supervision, un cas à part que nous couvrons ailleurs : ici, il s'agit d'une extension classique qui appelle un modèle d'IA dans le cadre d'une fonctionnalité définie. ## 1. Gestion des clés et des identifiants La clé API du fournisseur est-elle stockée côté serveur uniquement, jamais transmise au navigateur ? Est-elle chiffrée en base ou au minimum hors du dépôt de code versionné ? Existe-t-il une procédure documentée pour la faire tourner en cas de compromission suspectée, sans devoir modifier le code de l'extension ? ## 2. Limites et quotas Un plafond de dépense ou de nombre d'appels est-il configuré côté fournisseur pour éviter une facture incontrôlée en cas de bug ou d'usage abusif ? L'extension applique-t-elle elle-même une limite par utilisateur ou par période, indépendamment du plafond global du compte fournisseur ? ## 3. Comportement de repli Que se passe-t-il concrètement si l'appel échoue, dépasse le délai imparti, ou renvoie une réponse vide ? Ce comportement a-t-il été testé en simulant une panne réelle du fournisseur, pas seulement imaginé sur le papier ? > L'essentiel à retenir : Neuf familles de vérifications avant toute livraison client ; Le consentement utilisateur se traite en amont, pas après coup ; Un test de charge sur l'appel IA évite la mauvaise surprise du lancement ## 4. Journalisation Chaque appel est-il tracé avec un identifiant permettant de retrouver la requête envoyée, la réponse reçue, et le temps de traitement, sans pour autant journaliser des données personnelles au-delà du nécessaire ? Ces journaux sont-ils accessibles facilement en cas de réclamation client sur une réponse incohérente ? ## 5. Coûts prévisionnels Une estimation du coût mensuel a-t-elle été communiquée au client avant livraison, fondée sur un volume d'usage réaliste plutôt qu'optimiste ? Cette estimation a-t-elle été revue après les premières semaines d'usage réel, souvent différentes des projections initiales ? ## 6. Consentement et transparence utilisateur L'utilisateur final sait-il qu'il interagit avec un contenu généré ou traité par une IA, quand cette information est pertinente pour sa décision ? Ce point se traite en amont de la conception de l'interface, pas comme un ajout de dernière minute une fois la fonctionnalité terminée. ### Un principe simple à appliquer tôt Sur un projet récent, ajouter la mention « réponse générée automatiquement » sur un module de suggestions produit a nécessité une refonte mineure de l'interface parce que le sujet n'avait pas été anticipé au moment du design. Le traiter dès les maquettes évite ce genre de retour en arrière. ## 7. Tests de charge sur l'appel IA La fonctionnalité a-t-elle été testée sous une charge simulée représentative d'un pic de trafic réel, pas uniquement en conditions de développement avec un seul utilisateur connecté ? Le fournisseur d'IA applique-t-il ses propres limites de débit susceptibles d'être atteintes avant celles du serveur WordPress lui-même ? ## 8. Versionnage des prompts Les prompts utilisés sont-ils versionnés avec le reste du code, avec un identifiant tracé dans les journaux d'appel pour permettre de corréler une régression de qualité à un changement précis ? ## 9. Procédure de désactivation d'urgence Existe-t-il un interrupteur simple, accessible sans déploiement de code, permettant de désactiver la fonctionnalité IA en urgence si un problème grave est détecté après la mise en ligne ? - Clés côté serveur uniquement, avec procédure de rotation documentée - Quotas et plafonds configurés à deux niveaux, fournisseur et application - Comportement de repli testé en conditions de panne simulée - Interrupteur d'urgence accessible sans déploiement > Une checklist n'est utile que si elle est cochée avant la livraison, pas consultée après l'incident pour comprendre ce qui a manqué. ## En résumé Ces neuf familles de vérifications ne demandent pas un effort disproportionné une fois intégrées à l'habitude de l'équipe. Elles évitent en revanche la quasi-totalité des incidents que nous avons rencontrés sur des extensions IA livrées trop vite, où le code fonctionnait parfaitement en démonstration mais s'effondrait au premier imprévu réel.