Claude Opus 5.5 a fait le buzz avec le motion design. La cybersécurité pourrait être le sujet le plus important.

Les vidéos de la semaine de lancement étaient difficiles à manquer : typographies animées, films de présentation de produits, logos animés et scènes 3D réalisés avec Claude Opus 5.5.

Le détail intéressant, c’est la façon dont beaucoup ont été créées. La documentation des modèles d’Anthropic décrit une entrée combinant texte et image, avec une sortie textuelle, et non une génération vidéo native. Un répertoire public tenu par un tiers indique que de nombreux créateurs ont utilisé Claude pour écrire des animations en HTML, Canvas ou SVG, puis les ont enregistrées à l’écran ou rendues en vidéo. Au moment de notre vérification, le répertoire avait recensé 1 048 clips et 73,6 millions de vues sur X, mais précise aussi qu’il ne peut pas vérifier de manière indépendante comment chaque clip a été réalisé. Il faut considérer ces totaux comme un instantané de l’attention sur les réseaux sociaux, et non comme une mesure officielle du modèle.

Cette distinction met en lumière le sujet de fond. L’animation est le résultat visible ; en coulisses, le modèle suit une boucle : planifier, écrire du code, l’exécuter, examiner le résultat et le réviser.

Le motion design illustre la boucle agentique

Un brief créatif peut se transformer en une séquence d’actions :

Objectif → Planifier → Écrire du code → Exécuter → Examiner → Réviser

La sécurité des applications peut suivre une boucle similaire :

Comprendre l’application
  → Examiner le code et les comportements exposés
  → Formuler une hypothèse d’attaque
  → Tester dans un périmètre autorisé
  → Valider à partir des éléments observés
  → Expliquer l’impact et refaire le test après correction

Les deux domaines comportent des risques différents, mais leurs schémas de capacités sont proches. Un agent ne se contente pas de produire une première version : il peut utiliser des outils, observer les résultats et poursuivre son travail jusqu’à obtenir un résultat vérifiable.

C’est utile pour l’ingénierie logicielle. Cela soulève aussi une question pratique pour les équipes de sécurité : quand le code évolue plus vite, comment la vérification peut-elle suivre ?

Opus 5.5 vise les travaux de longue durée

Anthropic a lancé Claude Opus 5.5 le 22 septembre 2026 et l’a présenté comme un modèle destiné aux travaux de programmation avec des agents et de travail intellectuel de longue durée. Anthropic indique que les premiers testeurs l’ont utilisé pour achever en moins d’une journée une migration portant sur 680 000 lignes, et pour auditer et corriger en moins de trois heures une base de code de 200 000 lignes. Ce sont des exemples rapportés par le fournisseur, et non des estimations contrôlées de ce que chaque équipe peut attendre.

Les résultats publiés par Anthropic sur Opus et Sonnet placent aussi Opus 5.5 et Sonnet 5.5 à des niveaux proches sur certaines évaluations. Les scores rapportés sont notamment de 66,4 % contre 70,6 % sur Terminal-Bench 4.0, de 57,8 % contre 55,5 % sur CursorBench 4.0, et de 1 846 contre 1 844 sur GDPval-AA v2.1. Les résultats d’un benchmark dépendent du protocole, du niveau d’effort et du type de tâches ; Anthropic avertit elle-même que de faibles écarts de score ne permettent pas de prédire de façon fiable les performances en situation réelle. Pour certains tests, Anthropic a utilisé des niveaux d’effort différents ; les scores publiés ne constituent donc pas des comparaisons parfaitement équivalentes.

Sonnet 5.5 réduit le coût de répétition de la boucle

Anthropic a lancé Sonnet 5.5 le 28 septembre comme complément plus rapide et moins coûteux à Opus. Les tarifs API publiés dans la documentation des modèles Sonnet et Opus sont de 2 $ par million de jetons en entrée et de 10 $ par million de jetons en sortie, contre 4 $ et 20 $ pour Opus 5.5. Anthropic affirme également que Sonnet 5.5 génère ses réponses plus de 30 % plus vite que Sonnet 5 et peut coûter jusqu’à 30 % de moins par tâche que son prédécesseur.

Cela change l’économie du travail réalisé avec des agents. La question n’est plus seulement de savoir si un modèle peut mener à bien une longue série de tâches logicielles. Il s’agit aussi de déterminer à quelle fréquence les équipes peuvent se permettre de lancer ces séquences sur leurs dépôts, leurs pull requests et leurs processus de développement.

L’évaluation préliminaire de CodeRabbit sur la revue de code en donne un exemple circonscrit. Sur 13 cas difficiles où des bugs étaient connus, Sonnet 5.5 en a détecté 6 grâce à des commentaires exploitables, contre 4 pour Sonnet 5. Sur un autre ensemble de 44 pull requests open source, CodeRabbit a mesuré un temps moyen de revue de 6 minutes et 33 secondes pour Sonnet 5.5, contre 13 minutes et 31 secondes pour Sonnet 5. Les auteurs décrivent le premier échantillon comme réduit et précisent que l’étude plus large mesurait la charge de travail et la vitesse, pas la qualité des revues.

Ces résultats sont propres au processus de CodeRabbit. Ils ne constituent pas un classement universel, mais montrent pourquoi une revue plus rapide et moins coûteuse peut devenir une étape courante de la livraison logicielle.

Mieux coder ne signifie pas être sécurisé par défaut

Un modèle peut générer un logiciel fonctionnel sans respecter toutes les exigences de sécurité. Dans son évaluation de code Java produit par Opus 5.5, Sonar a constaté une densité de vulnérabilités inférieure de 9 % à celle d’Opus 5, ainsi que 27,5 % de code généré en moins. Dans le tableau des catégories de Sonar, les nombres bruts évoluent toutefois en sens différents : les constats d’injection passent de 7 à 17 et ceux de traversée de répertoires, de zéro à cinq. Le test de Sonar ne porte que sur un benchmark et un ensemble de code ; il ne mesure pas la sécurité de façon universelle. Il montre toutefois pourquoi une amélioration globale peut masquer une régression dans une catégorie de vulnérabilité précise.

L’Agent Security League d’Endor Labs a relevé un écart similaire dans son propre benchmark. Après application de son filtre anti-mémorisation, Opus 5.5 a réussi 68,7 % des tâches selon le critère fonctionnel, mais 33,5 % de celles qui exigeaient de satisfaire à la fois les critères fonctionnels et de sécurité. Ces taux concernent une évaluation précise de 179 tâches avec son propre environnement d’agent ; ils n’estiment pas la part du code généré dans son ensemble qui serait sécurisée. La conclusion plus limitée est qu’une réussite fonctionnelle ne suffit pas à établir qu’un comportement est sécurisé (évaluation d’Endor Labs).

Pour l’AppSec, la bonne question n’est donc pas simplement « Ce modèle est-il meilleur ? », mais « Quelles hypothèses de sécurité ce changement affecte-t-il, et pouvons-nous démontrer si le chemin qui en résulte est atteignable et exploitable ? »

Les décisions prises par Anthropic lors du lancement renforcent cette distinction. L’entreprise indique, dans son annonce d’Opus 5.5, que le modèle dispose de capacités avancées en cybersécurité et applique les garde-fous réservés à ses modèles les plus performants. Elle précise aussi, dans son annonce de Sonnet 5.5, que celui-ci est le premier modèle Sonnet lancé avec des garde-fous et un comportement de repli comparables en cybersécurité. Selon Anthropic, ces contrôles ciblent un ensemble restreint de requêtes à haut risque ; le développement logiciel courant n’est généralement pas affecté.

Les capacités en cybersécurité dépassent désormais la gamme de modèles la plus coûteuse. C’est une occasion pour les défenseurs, mais aussi une pression supplémentaire sur les programmes AppSec qui s’appuient encore sur un triage manuel lent.

La vitesse de vérification doit suivre celle du code

Les agents de programmation IA peuvent examiner des dépôts, modifier plusieurs fichiers, lancer des tests et réviser un changement. À mesure que le volume et le rythme de ces changements augmentent, demander à un spécialiste de la sécurité de vérifier chaque ligne à la main devient difficilement tenable. Lancer davantage d’outils d’analyse peut créer une nouvelle file de constats, sans montrer lesquels sont réels ou atteignables.

L’AppSec doit accélérer la vérification, pas seulement augmenter le volume de détection. Les processus de sécurité doivent :

• tester les chemins applicatifs dans un périmètre explicite et autorisé ;
• relier chaque constat au code et au flux de données qui expliquent son impact ;
• conserver les preuves et les incertitudes pour permettre leur examen ; et
• refaire les tests du comportement concerné après la correction.

C’est la logique de l’AppSec fondée sur des preuves : valider ce qui est réel, comprendre le chemin concerné et conserver les preuves tout au long de la correction et de la vérification. Davantage de génération exige davantage de validation. Davantage d’autonomie exige des preuves plus solides et un contrôle humain clair des décisions lourdes de conséquences.

On se souviendra peut-être d’Opus 5.5 pour le motion design. Pour les équipes de sécurité, la capacité à suivre est la boucle de travail avec des agents qui le rend possible — et la question de savoir si la vérification peut avancer au même rythme.