Comment les équipes financières peuvent déployer des applications créées avec l’IA sans divulguer de données financières

Lorsque RedAccess, une entreprise de sécurité, a recherché des applications créées avec des outils de codage par IA et publiées sur leur hébergement, elle en a trouvé plus de 5 000 pratiquement sans sécurité ni authentification. Parmi les captures transmises à Wired figuraient « divers documents commerciaux et financiers de plusieurs autres entreprises ». Les applications créées avec l’IA pour les équipes financières peuvent se retrouver à une adresse tout aussi ouverte, avec le grand livre, la paie et les résultats non annoncés derrière.

Amjad Masad, PDG de Replit, a répondu que « l’accessibilité des applications publiques sur Internet est le comportement attendu ». Il a raison sur le mécanisme. Selon moi, l’exposition venait d’un paramètre de visibilité et d’une vérification omise, deux éléments que la personne ayant créé l’outil peut corriger.

En bref

• Un outil financier créé avec l’IA peut divulguer des données à travers six erreurs de déploiement que son créateur peut corriger : lien public, mots de passe et clés laissés dans le code ou l’historique des conversations, accès administrateur à la base, écritures comptables sans second approbateur, données envoyées à des services externes et modifications de calcul non consignées.
• Chaque erreur a sa correction, souvent réalisable avec l’outil d’IA ayant créé l’application, et un contrôle concret pour vérifier son efficacité, comme une écriture refusée par la base ou un ancien mot de passe désormais inutilisable.
• Gardez l’outil financier sur un réseau privé par défaut, ajoutez la connexion d’entreprise quand des personnes hors de la finance en ont besoin et confiez-le à l’informatique s’il comptabilise sans second approbateur, traite des données de carte ou alimente des états financiers relevant de SOX.
• La région du serveur détermine l’emplacement du stockage principal du VPS, mais sauvegardes, journaux et services tiers peuvent créer des copies ailleurs. La conformité de l’ensemble reste une question distincte. Présentez les cadres de votre région à votre équipe conformité.

Les erreurs de déploiement qui divulguent les données financières

Un outil financier créé avec l’IA peut divulguer des données par six erreurs : lien public, identifiants dans le code ou les conversations, accès administrateur lorsqu’un accès en lecture suffit, comptabilisation sans second approbateur, envoi à des services externes et calculs modifiés sans trace. Ce sont des choix par défaut qu’une démo encourage.

Chaque correction ci-dessous s’accompagne d’un prompt pour l’outil d’IA ayant créé l’application ; adaptez les champs entre crochets avant de le coller. Ces prompts sont des points de départ non testés rédigés pour cet article. Le fait que l’IA affirme avoir effectué une modification ne prouve rien. Le contrôle sous chaque prompt constitue la preuve. Utilisez le code et un jeu de données exemple ou synthétique, sans jamais coller de vrais enregistrements ni de clés actives dans la conversation.

Laisser l’outil sur le lien public du générateur d’applications par IA

Un tableau de prévision de trésorerie public sur l’hébergement du générateur est accessible à toute personne connaissant son adresse, avec tout ce qu’il affiche : ancienneté des dettes fournisseurs, budget comparé au réalisé, résultats trimestriels avant publication. Le reportage de Wired sur les découvertes de RedAccess explique que les chercheurs ont localisé ces applications par de simples recherches Google et Bing sur les domaines des fournisseurs d’IA.

Certaines applications demandaient seulement une connexion avec n’importe quelle adresse e-mail. Une connexion acceptant toute adresse e-mail n’est pas un contrôle d’accès.

Retirez les données réelles de l’hébergement du fournisseur. Jusqu’à l’exécution sur un serveur que vous contrôlez, présentée dans la section suivante, développez et démontrez avec des données synthétiques ou le bac à sable ou la société de test de votre ERP, s’il en dispose, jamais avec un export réel. Redéployez après la modification : l’adresse hébergée sert la dernière version déployée.

Crée un jeu de données synthétique pour cette application correspondant aux tables et colonnes qu’elle lit : [liste des tables et colonnes, par exemple vendors, invoices, journal_lines].

Utilise des noms de fournisseurs et de clients inventés, des numéros de compte bancaire inventés et des montants en [devise] conformes au fonctionnement d’une comptabilité : chaque écriture est équilibrée et les totaux du grand livre auxiliaire concordent avec [le compte collectif fournisseurs / clients].

Connecte l’application à ces données plutôt qu’à un export réel et liste chaque fichier ou paramètre modifié.

Ne me demande pas de vrais enregistrements.

Vérifiez le résultat : ouvrez l’adresse hébergée chez le fournisseur dans un navigateur déconnecté, ou demandez à un collègue hors finance de le faire. Vérifiez qu’elle ne montre que des données synthétiques, une page de connexion ou rien. Recherchez ensuite trois noms de fournisseurs ou clients de votre ERP réel dans les fichiers de données et le dépôt : aucun résultat attendu. Enfin, vérifiez dans la balance ou la vue récapitulative que le total des débits égale celui des crédits.

Laisser les identifiants ERP, de flux bancaires et de base de données dans le code ou les conversations

Si un identifiant actif y est stocké, toute personne pouvant lire l’historique, le dépôt ou le fichier de configuration MCP peut aussi l’utiliser pour accéder à l’ERP, à la base financière ou à l’intégration bancaire. MCP est le connecteur permettant à un outil d’IA comme Claude de communiquer directement avec l’ERP ou une base. Son fichier de configuration est un autre emplacement possible pour un mot de passe.

Le rapport State of Secrets Sprawl 2026 de GitGuardian a trouvé 24 008 secrets uniques exposés dans des fichiers de configuration MCP, dont 14 % de chaînes de connexion PostgreSQL. Sur les commits GitHub publics, il a aussi observé que les commits cosignés par Claude Code divulguaient des secrets à environ deux fois le taux de référence, tout en soulignant le rôle essentiel du facteur humain.

Supprimer le message n’annule pas l’exposition : toute personne possédant une copie de la conversation, du dépôt ou de son historique conserve la valeur. Pour chaque mot de passe, clé ou jeton ayant figuré à ces endroits, émettez-en un nouveau dans la console d’administration de l’ERP, de la base ou du fournisseur bancaire, et désactivez l’ancien. C’est cela, la rotation d’un identifiant.

L’application lit ensuite ses identifiants au démarrage dans des variables d’environnement, des paramètres nommés conservés hors du code, fournis par la couche de déploiement, l’outil qui construit et exécute l’application sur votre serveur. HashiCorp Vault constitue l’étape suivante lorsque plusieurs outils partagent des secrets dont la rotation doit être centralisée.

Les copies de mots de passe de l’équipe doivent rester dans un gestionnaire destiné aux personnes, comme Vaultwarden ; l’application en cours d’exécution lit ses valeurs dans l’environnement. Commencez par trouver tous les secrets codés en dur dans le code généré par l’IA.

Audite ce projet pour trouver les secrets codés en dur. Repère chaque mot de passe, clé API, jeton d’accès et chaîne de connexion, y compris dans les fichiers .env, notebooks, configurations MCP et le code connecté à [nom de l’ERP / fournisseur de flux bancaires / base financière].

Remplace chaque valeur dans le code par une variable d’environnement nommée et donne-moi la liste de leurs noms.

Vérifie qu’aucun fichier contenant de vraies valeurs n’est enregistré dans le dépôt et liste chaque commit de son historique où une de ces valeurs apparaît.

Montre uniquement les emplacements. N’affiche aucune valeur secrète.

Vérifiez le résultat : essayez l’ancien mot de passe ou jeton, vous-même ou avec l’informatique : il doit être refusé. Recherchez ensuite les anciennes valeurs dans les fichiers actuels : aucune occurrence attendue. Une valeur encore dans l’historique ne cesse de donner accès qu’après confirmation de sa révocation ou expiration.

Utiliser la connexion administrateur du créateur alors que l’outil doit seulement lire

Un tableau d’ancienneté des créances clients ne doit pas pouvoir modifier le grand livre. Avec la connexion administrateur du créateur, l’outil hérite de ses privilèges. Une clé secrète Supabase, ou l’ancienne clé service_role, donne un accès élevé aux données et contourne Row Level Security ; elle ne convient donc pas à un accès ordinaire en lecture seule. Un rapport prévu pour un seul échéancier expose alors tout le grand livre, paie comprise.

Les écritures rendent cela coûteux. L’analyse de 1 072 applications créées avec l’IA par Symbiotic Security, utilisant Supabase, en a trouvé 172 permettant à n’importe qui de supprimer des enregistrements sans authentification, 172 permettant à n’importe qui de modifier des enregistrements existants et 39 dont les tables étaient entièrement lisibles par toute personne possédant la clé publique.

Donnez à l’outil un identifiant en lecture seule limité aux tables nécessaires. Dans l’ERP ou la base, créez un utilisateur d’intégration dédié : un compte distinct avec un accès en lecture aux seuls objets du rapport. Dans Supabase, activez Row Level Security, la règle déterminant quelles lignes chaque requête peut voir, pour toutes les tables exposées utilisées. Examinez aussi les droits de table : ils déterminent si un rôle peut sélectionner, insérer, modifier ou supprimer. Le rôle d’une application financière en lecture seule ne doit pas disposer d’écritures inutiles. La clé publiable peut figurer dans le navigateur si RLS et les droits minimaux sont correctement configurés. Les clés secrètes et anciennes clés service_role restent côté serveur, réservées aux tâches backend nécessitant réellement un accès élevé et imposant leur propre autorisation.

Remarque : une clé publiable Supabase ou une ancienne clé anon visible dans le JavaScript de la page est normale. La documentation des clés API de Supabase indique qu’elle n’accède qu’aux données permises par Row Level Security. La clé secrète contourne cette protection et ne doit jamais figurer dans ce qui est envoyé au navigateur.

Liste chaque lecture et écriture effectuée par l’application dans [nom de l’ERP ou de la base], par table ou objet.

Modifie l’application pour qu’elle lise seulement [les tables nécessaires] avec un identifiant distinct en lecture seule fourni par une variable d’environnement, jamais ma connexion personnelle.

Si l’application utilise Supabase : active Row Level Security pour chaque table exposée utilisée. Liste les droits select, insert, update et delete pour anon et authenticated. Pour cette application en lecture seule, retire les droits d’écriture inutiles ; si une autre application de production en dépend, signale-le sans les modifier. Écris ensuite des politiques interdisant toute lecture aux visiteurs déconnectés et limitant les utilisateurs connectés à [règle, par exemple les lignes de leur centre de coûts]. Vérifie qu’aucune clé secrète ou ancienne clé service_role ne figure dans un fichier envoyé au navigateur.

Liste les politiques créées.

Vérifiez le résultat : avec l’identifiant de l’outil, tentez une écriture, par exemple modifier un enregistrement de test : elle doit être refusée. Dans Supabase, demandez les lignes d’une table financière sans connexion : résultat vide ou erreur attendu.

Laisser l’outil comptabiliser dans le grand livre sans second approbateur

Un importateur d’écritures qui comptabilise directement, ou un générateur de fichiers de paiement qui les envoie directement à la banque, fait de la personne qui l’exécute à la fois le préparateur et l’approbateur. Un bug duplique un mois d’écritures de régularisation. Un champ modifié envoie un paiement fournisseur au mauvais compte. C’est la rupture de séparation des tâches que la finance refuse entre deux personnes, et un logiciel créé avec un assistant d’IA ne bénéficie d’aucune exemption.

Les dommages dépassent l’application. Un lot incorrect arrive dans les comptes ; l’annuler nécessite une écriture corrective et une explication à la clôture. Lorsque l’outil comptabilise sous la connexion de son créateur, chaque écriture dupliquée porte son nom.

L’outil créé avec l’IA lit et prépare ; la comptabilisation et la libération des paiements passent par le circuit d’approbation de l’ERP, avec un approbateur différent de l’utilisateur de l’outil. Chaque moteur comptable sur lequel j’ai travaillé distingue écriture et approbation comme deux événements avec deux responsables. L’outil créé avec l’IA mérite le même traitement.

Transformez chaque comptabilisation directe en brouillon ou import préparé attendant l’approbation dans l’ERP. L’outil conserve le travail fastidieux, mapping, validation et construction du lot, tandis que l’approbation reste dans l’ERP avec les autres approbations de clôture. Si l’ERP n’a pas d’étape d’approbation des imports, produisez un fichier qu’une seconde personne vérifie contre le récapitulatif du lot, puis importe elle-même.

Un outil devant comptabiliser automatiquement, générer des fichiers de paiement ou modifier les coordonnées bancaires fournisseurs relève de l’informatique, selon les conditions de la section suivante.

Liste tous les endroits où cette application crée, modifie ou comptabilise [écritures de journal / factures / paiements] dans [nom de l’ERP].

Modifie-les pour produire un brouillon ou un import préparé devant être approuvé dans [nom de l’ERP] avant comptabilisation. Si cet ERP n’a pas d’étape d’approbation des imports, produis un fichier d’import et ne comptabilise rien.

Supprime tout chemin de code comptabilisant ou libérant un paiement sans cette approbation.

Pour chaque lot, produis un récapitulatif du nombre de lignes, du total des débits et du total des crédits.

Liste ce qui comptabilise encore directement pour que je l’examine.

Vérifiez le résultat : exécutez un lot de données exemple. Rien ne doit être comptabilisé avant l’approbation d’un second utilisateur dans l’ERP. Comparez ensuite le récapitulatif avec le lot dans l’ERP : nombre de lignes, total des débits et total des crédits doivent correspondre exactement. Une ligne d’écart est un rapprochement échoué, pas un problème d’arrondi.

Envoyer des données financières à des services hors de votre contrôle

Une fonction de commentaire des écarts envoyant l’extraction complète du grand livre à une API d’IA transmet chaque ligne à un tiers. Deux voies plus discrètes existent : un script d’analyse de page rapportant chaque visite à son fournisseur, et un suivi d’erreurs ou un journal conservant les corps complets des requêtes, où peuvent finir des lignes de paie, coordonnées bancaires clients et chiffres non publiés.

Pour un outil interne créé par la finance, excluez résultats non publiés et paie des appels tiers sauf approbation explicite du service et du flux exact par les procédures fournisseurs, sécurité et conformité de votre organisation. Pour le reste, listez chaque destination et n’envoyez que les champs nécessaires. La conservation ou l’utilisation pour l’entraînement relève de la personne signant les accords fournisseurs, après vérification des conditions du fournisseur. Pour suivre l’usage de l’outil, un outil d’analyse auto-hébergé comme Umami conserve ces visites sur votre serveur.

Liste chaque endroit où l’application envoie des données hors de [notre serveur], y compris API d’IA, scripts d’analyse, suivi d’erreurs, e-mails, webhooks et fichiers journaux.

Pour chaque destination, liste exactement les champs reçus.

Signale tout élément contenant [montants de paie / numéros de compte bancaire / résultats non publiés / noms de clients].

Pour chaque élément signalé, montre comment envoyer moins de champs ou aucun, et ne modifie qu’après ma confirmation.

Vérifiez le résultat : déclenchez chaque fonction avec des données exemple contenant un faux numéro de compte reconnaissable et un faux montant de paie. Recherchez les deux valeurs dans le suivi d’erreurs et les journaux : aucune occurrence attendue. Pour l’API d’IA, journalisez le corps de la requête sortante pendant ce test et recherchez ces valeurs : aucune ne doit apparaître, seuls les champs approuvés doivent être présents. Désactivez ensuite cette journalisation.

Modifier les calculs sans trace ni rapprochement

Dans un calculateur de régularisations comptables ou un validateur de cascade de revenus, le code constitue le contrôle. Une formule modifiée change les chiffres de clôture ; sans gestion de versions, personne ne peut dire qui a changé quoi ni quand.

Dans un fil r/ClaudeAI d’un cabinet de CPA sur ses outils internes créés avec Claude Code, un commentaire résumait la limite : « “comptable + claude code” fonctionne jusqu’aux exigences de piste d’audit. Voilà le vrai plafond. »

Figez le comportement actuel avant toute modification. Une fois les sorties figées, la logique peut évoluer sans dérive silencieuse des totaux. Conservez le code sous gestion de versions, qui enregistre chaque modification avec auteur et date.

Écrivez des tests exécutant l’outil sur un fichier exemple fixe et comparant les résultats à une référence enregistrée, afin d’imposer un rapprochement avant toute livraison. Un test figé protège aussi les erreurs enregistrées : rapprochez donc les totaux de référence des totaux ERP de la période avant de leur faire confiance.

Exigez une seconde personne pour examiner chaque modification des calculs et rapprochez chaque exécution de production des totaux de l’ERP.

Place ce projet sous gestion de versions s’il ne l’est pas et liste les fichiers contenant la logique de calcul.

Écris des tests exécutant l’application sur [fichier exemple] et enregistrant les sorties actuelles : nombre de lignes et totaux par [compte / entité / période].

Avant d’enregistrer les sorties, montre-moi les totaux pour les rapprocher de [nom de l’ERP] pour [période].

Toute modification changeant un de ces totaux doit faire échouer un test.

Ne modifie pas la logique de calcul pendant l’écriture des tests.

Vérifiez le résultat : modifiez volontairement un calcul, par exemple une règle d’arrondi, et vérifiez qu’un test échoue. Annulez la modification et vérifiez que tous les tests réussissent à nouveau.

Privé par défaut, connexion d’entreprise pour élargir l’accès, informatique pour le grand livre

Les données financières réelles ne restent jamais sur l’hébergement de l’outil d’IA. Pour déployer en sécurité une application réservée à la finance, utilisez un serveur contrôlé par vous et accessible seulement sur un réseau privé. Ajoutez la connexion d’entreprise quand d’autres personnes en ont besoin et confiez-la à l’informatique si une des conditions ci-dessous s’applique.

Un VPS est un serveur virtuel loué dont vous contrôlez le système et les logiciels. Un réseau privé, un tailnet chez Tailscale, relie les appareils approuvés à ce serveur. Pour retirer l’outil d’Internet, bloquez aussi l’accès public entrant à l’application, par exemple avec le pare-feu, et exposez-la seulement sur l’interface VPN ou tailnet. Le fournisseur d’identité détient les comptes d’entreprise ; le reverse proxy devant l’application fait passer chaque requête par l’authentification.

L’hébergement de l’outil d’IA est exclu pour les raisons de la première erreur. Une plateforme de déploiement d’entreprise comme Northflank l’est aussi : elle convient aux grandes organisations ayant déjà un budget pour les fournisseurs de plateformes et les examens qu’ils exigent. Ce cadre contractuel dépasse les besoins d’un outil départemental pour quelques utilisateurs.

D’après mon expérience, Tailscale est la plus rapide des deux options de réseau privé à déployer, mais Tailscale héberge lui-même le service de coordination. WireGuard est l’option entièrement auto-hébergée.

Mon raisonnement pour choisir le réseau privé par défaut : un outil ne répondant pas depuis Internet ne peut être trouvé par recherche ni attaqué à sa page de connexion, alors qu’une connexion créée par l’IA dépend de la qualité de son code. Si l’application doit dépasser le réseau privé, la connexion d’entreprise ajoute une couche d’authentification gérée en amont, d’où sa deuxième place.

Quand les responsables budgétaires ont besoin d’accès, remplacez la connexion propre à l’outil par celle de l’entreprise, ou authentification unique (SSO). Les personnes utilisent leur compte existant ; le désactiver bloque les nouvelles connexions. Configurez révocation de sessions, déconnexion back-channel ou durées suffisamment courtes pour éviter les sessions persistantes. Le prompt utilise OIDC, un protocole standard pris en charge par Authentik et Keycloak.

Remplace la connexion de cette application par la connexion d’entreprise via [Authentik / Keycloak / notre fournisseur d’identité] avec OIDC.

Lis le groupe de chaque utilisateur depuis la connexion.

Réserve [les pages de paie] aux membres de [nom du groupe] et impose cette règle côté serveur pour chaque page, export et endpoint API, pas seulement dans le menu.

Refuse toute requête sans connexion valide.

Vérifiez le résultat : connectez un compte de test hors du groupe, demandez directement la page restreinte et son export ou API : les deux doivent être refusés. Désactivez ensuite le compte dans le fournisseur d’identité et vérifiez qu’il ne peut ouvrir une nouvelle session. Vérifiez aussi que la session existante est révoquée ou expire dans le délai configuré.

Certains outils ne doivent pas rester dans l’équipe. Confiez-les à l’informatique ou l’ingénierie si l’une de ces conditions s’applique :

1. Il comptabilise dans le grand livre ou un autre système de référence sans approbation humaine dans l’ERP.
2. Il génère des fichiers de paiement, libère des paiements ou modifie les coordonnées bancaires fournisseurs.
3. Ses sorties alimentent les états financiers d’une entreprise enregistrée auprès de la SEC, ce qui peut le faire entrer dans le contrôle interne de l’information financière (ICFR). Consultez l’audit interne avant utilisation en clôture ; pour les émetteurs soumis à SOX Section 404(b), l’auditeur externe peut aussi tester les contrôles concernés.
4. Il stocke, traite ou transmet des données de carte de paiement.
5. Il évalue la solvabilité de personnes physiques.
6. Personne dans l’équipe ne prendra en charge les correctifs, les revues d’accès et son retrait.

La sixième condition pèse plus qu’il n’y paraît. En auto-hébergement, vous assumez les mises à jour, sauvegardes et la surveillance. Un outil financier sans maintenance est plus sûr avec l’informatique. Elle peut être plus lente ; c’est le prix de la gouvernance requise.

Pour les niveaux 1 et 2, serveur, couche de déploiement, réseau privé et, au niveau 2, fournisseur d’identité doivent être prêts avant toute utilisation. Une équipe financière sans ingénieur doit les installer elle-même. Notre Linux VPS donne un accès root. Coolify et WireGuard existent en déploiement en un clic ; Tailscale s’installe avec son installateur officiel à une commande, et Authentik avec sa stack Docker Compose officielle. L’équipe peut consacrer ses heures aux corrections précédentes plutôt qu’à construire la stack. Nos implantations comprennent Francfort et Amsterdam dans l’UE, Londres au Royaume-Uni et plusieurs villes américaines, pour choisir la région du stockage principal du VPS. La conformité de ce choix reste à valider par votre équipe conformité.

Règles à vérifier avec votre équipe conformité, par région

Les cadres applicables dépendent des données traitées et de la localisation de l’entreprise et des personnes concernées. Une table de salaires d’employés européens et un échéancier de revenus alimentant les états financiers d’une société cotée aux États-Unis peuvent relever de cadres différents.

Cet article ne fournit aucun conseil juridique. Le tableau répertorie des cadres à présenter à votre équipe conformité, sans déterminer leur applicabilité à votre situation.

Pour SOX, AS 2201 est la norme PCAOB d’attestation de l’auditeur visée par la Section 404(b) de Sarbanes-Oxley. Elle cite les contrôles des écritures et ajustements du processus d’information financière de fin de période parmi ceux évalués pour le risque de fraude. Hors de ces régions, commencez par le site du régulateur national de protection des données. La localisation du serveur indique celle du stockage principal, pas de chaque sauvegarde, journal ou copie tierce ; elle ne satisfait à elle seule aucun de ces cadres.

Foire aux questions

Le vibe coding est-il sûr pour les outils financiers ?

Il peut l’être après correction des lacunes d’une démo ; selon moi, les éléments pointent davantage vers un problème de déploiement que de codage. Un outil financier est plus risqué qu’un projet personnel puisqu’il lit l’ERP et peut écrire dans les comptes. Dès qu’il comptabilise sans second approbateur, gère des paiements ou traite des données de carte, il relève de l’informatique.

Qu’est-ce que le shadow AI en finance ?

Le shadow AI désigne les outils d’IA ou applications créées avec l’IA utilisant des données d’entreprise sans connaissance ni approbation de l’informatique, comme un tableau prévisionnel connecté à l’ERP qu’elle n’a jamais vu. Le rapport Cost of a Data Breach 2025 d’IBM indique que les organisations fortement exposées au shadow AI avaient des coûts moyens de violation supérieurs de 670 000 $ à celles peu ou pas exposées, selon l’annonce d’IBM.

Que présenter à l’audit interne ou à l’auditeur externe ?

Présentez quatre éléments avant utilisation en clôture : lieu d’exécution et accès, historique des changements avec tests de sorties figées, approbation des écritures dans l’ERP et preuves du rapprochement de chaque lot avec les totaux ERP. L’auditeur décide de ses exigences ; ces éléments lui donnent une base concrète d’évaluation.

Qui prend en charge l’outil financier créé avec l’IA après le départ de son créateur ?

Nommez un responsable financier et un contact technique avant lancement. Utilisez un identifiant de service plutôt que la connexion du créateur et faites passer l’accès par la connexion d’entreprise : désactiver le compte d’un salarié parti bloque les nouvelles connexions, les sessions existantes étant révoquées ou expirant selon votre politique. Pour retirer l’outil, désactivez ses identifiants, conservez ce qu’exige la politique de conservation, supprimez le reste et arrêtez-le.