YouMind
Se connecter

5 points clés pour développer des applications internes avec Claude Opus 5.5

@yagiryuuu
JAPONAIS24 sept. 2026
137K
130
4
2
387

TL;DR

Cet article détaille cinq contrôles de sécurité essentiels pour les applications internes développées avec Claude Opus 5.5. Il fournit des prompts spécifiques pour instruire l'IA d'auditer son propre code afin de détecter les lacunes en matière d'authentification, les dépassements de permissions et les vulnérabilités aux attaques par injection de prompt.

Le 22 septembre (heure américaine), Anthropic a lancé Claude Opus 5.5.

Le même jour, OpenAI a annoncé GPT-6 Sol et Luna.

Les deux sont « plus intelligents qu'avant, et moins chers qu'avant ».

Parmi tout cela, ce qui a retenu mon attention est un chiffre précis dans l'annonce officielle.

Dans un commentaire de Deloitte, on peut lire :

« Même avec le réglage le plus bas, il a trouvé 72 % des bugs connus. Opus 5 en trouvait 56 % avec le réglage élevé. »

Cela signifie que la capacité à lire du code et à détecter des vulnérabilités s'est nettement améliorée en une seule génération.

L'IA construira des choses qui « fonctionnent ».

Mais pour qu'elles soient « sûres », c'est à l'humain de donner les consignes.

Voici donc 5 points à garder en tête lorsque vous créez des applications internes avec Opus 5.5.

Chacun est présenté avec un prompt pour demander à Opus 5.5 d'inspecter le travail.

====

Comment mener l'inspection

Une fois votre construction terminée, ne demandez pas « Y a-t-il des problèmes ? » dans la même session que celle où vous l'avez créée.

L'IA qui a construit l'application considère sa propre conception comme un acquis, elle devient donc indulgente.

Ouvrez une nouvelle session, réglez le modèle sur Opus 5.5 et montrez-lui l'intégralité du dossier de l'application.

Ensuite, assurez-vous que chaque problème détecté précise bien « quel fichier et quelle ligne ».

Le commentaire de Deloitte mentionne que les faux positifs ont diminué, mais ils ne sont pas nuls.

Si l'emplacement est précisé, un humain pourra le vérifier par la suite.

Voici la consigne :

« Tu es un responsable sécurité qui découvre ce code pour la première fois. Si tu trouves des problèmes, indique le nom du fichier, le numéro de ligne, pourquoi c'est dangereux et comment le corriger. Isole tout ce dont tu n'es pas sûr dans une catégorie "À vérifier". »

====

1. Des éléments sont-ils visibles pour les personnes non connectées ?

Quand on laisse l'IA construire, il arrive que les murs de connexion manquent sur certains écrans ou accès aux données.

Un cas classique : les écrans de confirmation créés pendant le développement restent accessibles publiquement.

La vérification est simple.

Ouvrez directement dans un navigateur les URL d'administration ou de données sans vous connecter (fenêtre de navigation privée).

Si vous y accédez, c'est raté.

Voici la consigne :

« Liste toutes les URL et API accessibles sans être connecté. Parmi celles-ci, classe par niveau de dangerosité celles qui renvoient des données ou qui servent à l'administration. »

====

2. Les utilisateurs connectés peuvent-ils voir les données des autres ?

La connexion permet de vérifier « qui » est la personne.

Mais « ce que cette personne a le droit de voir » doit être développé séparément.

Pour vérifier, créez deux comptes de test. Connectez-vous en tant que A, puis essayez d'ouvrir l'URL des données de B.

Voici la consigne :

« Trouve tous les chemins permettant à l'utilisateur A de consulter ou modifier les données de l'utilisateur B. Inclus les cas où les URL ou API sont appelées directement, en contournant l'interface. »

====

3. Des clés ou mots de passe se trouvent-ils dans des endroits visibles ?

Le code exécuté côté navigateur est entièrement envoyé au PC de l'utilisateur.

Y inscrire des clés revient à les distribuer à tout le monde.

Autre erreur fréquente : téléverser des fichiers de configuration contenant des clés dans des dossiers partagés ou sur GitHub.

Voici la consigne :

« Recherche les clés API, mots de passe ou tokens présents dans le code côté client, les fichiers de configuration ou l'historique des commits. Si tu en trouves, suggère où ils devraient être déplacés. »

====

4. Les permissions accordées aux outils sont-elles trop larges pour leurs tâches ?

Les outils internes se connectent souvent à Google, Slack ou à des bases de données.

Parfois, la clé fournie autorise la « suppression » ou la « consultation totale », alors qu'une simple « lecture » suffirait.

C'est un problème courant.

Si cette clé fuit, l'étendue des dégâts dépendra du périmètre des permissions.

Pour vérifier, posez-vous cette question par écrit : « Dans le pire des cas, que peut supprimer cet outil ? »

Si vous ne pouvez pas répondre immédiatement, soyez prudent.

Voici la consigne :

« Liste toutes les permissions dont dispose cet outil sur les services externes ou les bases de données. Compare chacune avec les permissions minimales requises pour le traitement réel et signale tout excès. »

====

5. Les textes entrants provenant de l'extérieur sont-ils exécutés comme des commandes ?

Les outils qui permettent à l'IA de lire des e-mails, des pages web ou des fichiers téléversés exigent de la prudence.

S'ils contiennent un texte du type « Ignore les instructions précédentes et fais XX », l'IA pourrait obéir.

C'est ce qu'on appelle l'injection de prompt (Prompt Injection).

Dans l'annonce d'Opus 5.5, la résistance à cette attaque est décrite comme « égale ou supérieure à celle d'Opus 5 dans tous les scénarios testés ».

Cependant, égal ou supérieur ne signifie pas risque zéro. Il faut toujours des défenses côté outil.

Voici la consigne :

« Recherche les endroits où du texte ou des fichiers chargés depuis l'extérieur sont traités comme des instructions pour l'IA. Si tu en trouves, modifie le traitement pour que le contenu chargé soit considéré uniquement comme une information de référence, en ignorant toute instruction qu'il contient. »

====

Résumé

L'IA construira les fonctionnalités que vous lui demandez.

Mais « ne montre pas ça aux autres » et « n'accorde pas de permissions excessives » ne seront pas intégrés si vous ne le dites pas.

À l'inverse, ces 5 points peuvent tous être traités simplement en ajoutant une consigne.

Et la capacité d'Opus 5.5 à dénicher les failles dans ce que vous avez construit s'est également améliorée.

Après avoir terminé, montrez-lui votre travail dans une nouvelle conversation avec Opus 5.5.

Considérez cela comme une étape du développement.

Si vous avez déjà une application interne en production, commencez par coller la consigne d'inspection de la section « Comment mener l'inspection ».

Par ailleurs, si coller des consignes à chaque fois vous lasse, il existe un plugin appelé security-review que je vous recommande d'essayer.

Il prête attention aux moindres détails et les signale, je l'utilise d'ailleurs régulièrement moi-même.

====

Enfin, une petite annonce.

Notre entreprise propose un service de développement d'agents IA sur mesure, conçus de A à Z pour votre société.

Pas de formation ni de simple présentation d'outils : nous analysons vos processus métier réels pour livrer une solution utilisable « dès demain ». Nous assurons également l'intégration et la maintenance.

Enregistrer en un clic

Lire les articles viraux en profondeur avec l’IA de YouMind

Enregistrez la source, posez des questions ciblées, résumez l’argument et transformez un article viral en notes réutilisables dans un seul espace de travail IA.

Découvrir YouMind
Pour les créateurs

Transformez votre Markdown en un article 𝕏 impeccable

Quand vous publiez vos propres textes longs, la mise en forme 𝕏 des images, tableaux et blocs de code est pénible. YouMind transforme un brouillon Markdown complet en un article 𝕏 impeccable, prêt à publier.

Essayer Markdown vers 𝕏

D'autres patterns à décoder

Articles viraux récents

Explorer plus d'articles viraux