Code Guardian 17.3 : ce qui change pour vous

Code Guardian 17.3 est disponible dans le portail client depuis le 02.10.2026. Après la mise à jour, vous serez moins souvent interrompu, en fin de session comme lors de commandes ordinaires. En contrepartie, douze verrous sont désactivés : vos contrôles ne sont plus qu'une consigne de travail. Vous lirez ici quels blocages relèvent désormais de vous et ce que vous devriez faire avant et après la mise à jour.

Ce que vous devriez faire maintenant :

• Parcourez le tableau des blocages désactivés ci-dessous. Là où vous comptiez sur l'un d'eux, le contrôle doit désormais figurer dans votre propre démarche. La sortie de la mise à jour indique ceux qui étaient actifs chez vous, sur la ligne « REMOVED (Riegelkern, …) ».
• Utilisez-vous des rapports de validation pour les migrations ? Recréez alors vos anciens rapports en suivant les instructions ci-dessous. Un rapport sans la ligne FREIGABE-FUER ne valide plus rien.
• Avez-vous besoin du gate juridique ou du gate d'analyse de données ? Activez-les alors (instructions ci-dessous).
• Utilisez-vous Codex ? Vérifiez alors avant la mise à jour, avec codex --version, que vous disposez au moins de la version 0.150.0.

Qu'est-ce que le noyau de verrous (Riegelkern) ?

Un verrou est un contrôle qui peut arrêter une commande ou une action. Jusqu'ici, un très grand nombre d'entre eux s'activaient. Dans la 17.3, seuls bloquent encore les verrous dont le potentiel de dommage est réel.

• DESTRUCTIVE arrête les commandes de suppression risquées.
• COMMIT-SECRET arrête un commit contenant un secret.
• DEPLOY arrête une mise en production pour laquelle aucun rapport validé n'existe.
• MIGRATION arrête les modifications de base de données pour lesquelles aucun rapport de validation n'existe.
• La protection en écriture pour les exécutions sans surveillance est définie de façon étroite. Elle ne bloque plus que la protection propre des verrous et des fichiers de configuration, ainsi que l'écriture d'identifiants d'accès.
• Le DECISION GATE n'arrête plus une question à options que dans l'autopilote. C'est là que le llm-council tranche. Sinon, il se contente d'un avertissement.

Indépendamment des douze verrous désactivés ci-dessous, d'autres hooks, dont le démarrage de session et le contrôle de prompt, ne donnent plus que des avertissements.

Pour vous, cela signifie : vous recevez moins de questions et de refus. Les quatre verrous de commande continuent de vous protéger contre la suppression, les secrets dans un commit, la mise en production et la migration.

Quels blocages relèvent désormais de vous ?

Il s'agit d'une restriction, pas d'une amélioration. Les règles figurent toujours dans le skill, mais une infraction ne vous arrête plus techniquement. Si vous comptiez sur l'un de ces blocages, par exemple sur l'arrêt d'une nouvelle installation de paquet, vous devez désormais assurer le contrôle vous-même. Cela vaut aussi pour la preuve du second relecteur à froid, c'est-à-dire d'un contrôleur indépendant qui lit votre modification sans connaissance préalable.

La clôture de périmètre (scope fence) figure sur une seule ligne, car deux fichiers lui appartiennent (l'un fixe le périmètre, l'autre bloquait les écritures en dehors).

La mise à jour supprime les entrées de ces verrous de votre settings.json. Un hook du même nom dans un autre dossier, que vous avez enregistré vous-même, est laissé en place. Les fichiers des verrous désactivés restent dans cette version, dans le paquet et dans ~/.claude/hooks/, mais ne s'exécutent plus. Leur suppression est prévue pour la v17.4.

Comment recréer un rapport de validation pour les migrations ?

Un rapport de validation ne vaut désormais que pour les types de commandes que nomme sa ligne FREIGABE-FUER: <arten>. L'outil l'écrit lors de la recréation avec la valeur par défaut migrate. Un ancien rapport n'a pas cette ligne et ne valide donc plus rien.

L'appel de l'outil de rapport gate-report.py dans le skill code-guardian est le suivant :

gate-report.py migration (--files F... | --git [--ref REF]) [--wurzel DIR] [--fuer ART[,ART]]

1. Recréez le rapport avec l'outil, soit avec --files et les fichiers de migration, soit avec --git.
2. S'il doit valider plus que migrate, nommez les types avec --fuer, par exemple --fuer migrate,seed. Sont autorisés : migrate, seed, rollback, fresh, refresh, reset, wipe et ddl. Ne précisez les types destructeurs que de façon expresse.
3. Vérifiez dans le rapport terminé que la ligne FREIGABE-FUER est présente et nomme les types souhaités.

Quelles corrections de sécurité la 17.3 contient-elle ?

Il s'agit de corrections apportées aux verrous qui continuent de bloquer. Les commandes qui passaient jusqu'ici sans contrôle sont désormais vérifiées.

• Un rapport de validation pour une migration autorisait jusqu'ici toute commande de migration de la même racine de projet, y compris migrate:fresh et migrate:rollback. Désormais, il n'autorise que les types qui figurent dans FREIGABE-FUER. Vous le remarquerez tout de suite si votre rapport est ancien.
• Une commande de suppression écrite sous deux formes imbriquées précises échappait au verrou de suppression. Il vérifie maintenant les deux.
• Lorsqu'une indication était transmise deux fois à l'outil de rapport, une migration disparaissait silencieusement du rapport, et le rapport la jugeait trop anodine. Désormais, les deux indications sont prises en compte. Vous recréez de toute façon les anciens rapports (voir ci-dessus).

Comment activer le gate juridique et le gate d'analyse de données ?

Les deux gates sont désormais activables et désactivés par défaut. Pour les activer, saisissez cette ligne dans ~/.claude/code-guardian.conf :

riegel_zusatz = rechts, data-analytics

Exécutez ensuite bash install.sh. Si vous ne voulez que l'un des deux, ne nommez que celui-là.

Pour vous, cela signifie : si vous rédigez des textes juridiques ou des analyses de données, activez les gates. Jusqu'ici, les deux étaient actifs ; ils sont désormais désactivés tant que vous ne les activez pas.

Quelles limites restent ouvertes ?

D'abord les limites qui concernent votre démarche :

• Verrous de migration et de mise en production : dans certaines formes de commande et d'écriture, le verrou de migration n'associe pas encore dans tous les cas une migration ou son rapport de validation à la bonne racine de projet. Le verrou de mise en production ne reconnaît un script de transfert que par des noms connus. Les deux points sont prévus pour la v17.4. D'ici là, vérifiez vous-même, pour vos propres scripts et pour les formes de commande inhabituelles, si le verrou a bien agi.
• Rapport de validation : il est lié à des types de commandes, non à un fichier de migration précis.
• Corrections de sécurité : elles concernent des écritures connues. Nous n'affirmons pas que toutes les formes sont ainsi couvertes. Pour les commandes de suppression, ne vous fiez pas uniquement au verrou.
• Sous-agents de contrôle : ils travaillent dans l'arbre de travail partagé. Qu'ils ne touchent pas, à cet endroit, au travail d'autrui non encore versionné est, dans cette version, une consigne de travail. Sauvegardez au préalable le travail non versionné.

Et les limites de certains contrôles :

• La recherche de secrets reconnaît des formes connues d'identifiants dans du texte lisible et n'effectue aucune analyse de flux de données. Pour un fichier dans un encodage sur deux octets (UTF-16), elle ne peut contrôler que de façon limitée.
• design-beweis mesure peut-être trop tôt les pages qui ne construisent leur contenu qu'après le chargement. Il n'évalue pas le contraste sur les pages à thème de couleurs commutable. La correction est prévue pour la v17.4.
• Codex uniquement : avec un CODEX_HOME personnalisé, certaines indications de réparation renvoient encore vers ~/.codex, et l'analyse des incidents en fin de session n'a pas lieu. La correction est prévue pour la v17.4.

Pour vous, cela signifie : pour les migrations et les mises en production, jusqu'à la v17.4, ne comptez pas uniquement sur le déclenchement du verrou.

Quoi de neuf pour la recherche de secrets et les contrôles d'analyse ?

Les deux disent désormais « non mesuré » ou « non contrôlé » là où ils auraient auparavant affiché un résultat vert.

• La recherche de secrets range chaque fichier dans exactement une classe et indique, avec leur nombre, ce qu'elle n'a pas parcouru (« non contrôlé : … »).
• Jusqu'ici, elle ne cherchait que dans les fichiers à extension connue. Un fichier PowerShell, un .ini, un .toml ou un Dockerfile passaient silencieusement pour propres. Désormais, ils sont parcourus.
• Si rien n'a été parcouru alors que des fichiers étaient présents, le résultat n'est pas « propre ». Si python3 manque, la recherche indique « non contrôlé ».
• Si un outil d'analyse configuré manque, plante ou dépasse son délai, les contrôles d'analyse indiquent « non mesuré ». Vous réglez le délai avec CG_ANALYSE_FRIST. La valeur par défaut est de 900 secondes.

Précision honnête : un fichier contenant une très longue suite de caractères sur une seule ligne peut faire durer la recherche de secrets de quelques secondes à plus d'une demi-minute. Le résultat reste complet.

Pour vous, cela signifie : là où rien n'a été contrôlé, le résultat n'affiche plus du vert, il le dit.

Que devient la ligne d'état ?

La ligne d'état est supprimée. Avec de nombreuses sessions parallèles, elle coûtait sensiblement du temps de calcul. Code Guardian n'en enregistre plus, et une mise à jour supprime celle que nous avions enregistrée auparavant :

• Une ligne combinée revient à votre propre commande.
• Une ligne d'état personnelle reste inchangée.
• Si vous avez intégré notre ancien script autrement que ne l'a jamais écrit l'installateur, la ligne reste en place avec un avertissement. Nettoyez-la alors vous-même si nécessaire.
• Les anciens commutateurs --statuszeile=… et --statuszeile-kombinieren sont toujours acceptés et ignorés.
• La copie sauvegardée de votre ancienne ligne d'état n'est pas supprimée si elle peut être la seule copie.
• Le skill de tableau de bord clistatus demeure.
• Le repère orange, censé montrer qu'un verrou était intervenu, disparaît avec la ligne d'état. L'intervention d'un verrou ne dépend pas de la ligne d'état.

Pour vous, cela signifie : si vous aviez une ligne d'état personnelle, rien ne change. Si vous aviez la nôtre, la mise à jour la supprime. Seule une intégration que l'installateur n'a jamais écrite reste en place, avec un avertissement.

Qu'est-ce qui change sous Windows et au démarrage de session ?

• Avec un jq.exe natif, l'avertissement de résultat nul n'apparaissait jamais. Désormais, il apparaît.
• Le contrôle de prompt est plus rapide. Son traitement de texte par prompt se fait en un seul appel python3 au lieu de nombreux petits processus.
• Lorsqu'un verrou avait signalé lui-même une défaillance, le démarrage de la session suivante était sensiblement plus lent, surtout sous Windows. L'analyse du journal des défaillances lançait de nombreux petits processus et s'effectue maintenant en un seul passage. Le message est inchangé.
• Si l'analyse échoue, le démarrage de session le signale sur une ligne visible et laisse le journal en place. Auparavant, il le déplaçait silencieusement dans l'historique.

Pour vous, cela signifie : après une défaillance de verrou, la session suivante démarre plus vite sous Windows, et une erreur ne passe plus inaperçue.

Quoi de neuf pour les réglages, les outils et la documentation ?

L'installateur reprend désormais votre choix dans code-guardian.conf même si le fichier existe déjà. Un réglage documenté qui y manque encore est ajouté à la fin avec sa valeur par défaut. Vos lignes restent inchangées.

Les outils reçoivent de petites modifications. jsqa-onboard active la trace Playwright en cas d'échec. La liste de tâches vérifie ses règles de forme avant d'écrire. Le skill session-orchestrator dispose d'une boîte de réception des commandes avec échéance et crée un arbre de travail distinct pour chaque session. La documentation est corrigée : les chiffres obsolètes sont remplacés, et Windows est mentionné comme plateforme prise en charge.

Qu'est-ce qui change pour les utilisateurs de Codex ?

La recherche de secrets, les contrôles d'analyse, les corrections de sécurité, les réglages et l'analyse plus rapide du journal des défaillances au démarrage de session correspondent à la version Claude. L'avertissement jq.exe et le contrôle de prompt plus rapide ne valent que pour Claude Code. Voici ce qui diffère :

• La nouvelle condition requise est codex-cli 0.150.0 ou plus récent. La mise à jour s'interrompt sans rien modifier si codex ne se trouve pas dans le PATH ou s'il est plus ancien. Vérifiez avec codex --version. Vous pouvez mettre à jour par exemple avec npm install -g @openai/codex@latest.
• Les verrous désactivés ne sont pas les mêmes sous Codex que dans le tableau ci-dessus. N'y sont plus branchés, entre autres, l'airlock avant la première modification de fichier, la clôture de projet, le verrou de dépendances et tous les verrous de fin de session. Leurs règles figurent toujours comme consigne de travail dans les skills.
• Les verrous supplémentaires pour les textes juridiques et l'analyse de données ne peuvent pas être activés sous Codex dans cette version.
• L'indication que Codex affiche à chaque prompt ne nomme plus d'outils qui n'existent que dans Claude Code. Elle exige à la place un plan avec update_plan et la réponse de l'humain.

Pour vous, cela signifie : vérifiez la version de Codex avant la mise à jour. Cela vous évite une exécution interrompue.

Comment la 17.3 a-t-elle été testée, et que dit la mesure comparative ?

La 17.3 est passée par la batterie de tests avant la publication. Le tableau présente les chiffres en comparaison avec la 17.2.

Pour situer : 16 niveaux sont nouveaux. Un a disparu, celui de la ligne d'état. Les deux directions d'erreur des verrous ont été entièrement réussies : ils se déclenchent à raison, et ils laissent passer à raison ce qui est permis.

Depuis l'article sur la 17.2, il n'existe aucune nouvelle mesure comparative valide. Pour la 17.3, nous ne pouvons donc citer aucun chiffre, et nous n'en inventons pas. Sur l'ensemble des comparaisons valides de la v16.116 à la 17.2 (8 mesures), le constat reste : 4 avec une différence attestée, 3 non tranchables, 1 sans différence attestée.

Conclusion : la batterie de tests s'est déroulée sans échec ; cinq niveaux ont été ignorés en mode rapide, avec indication du motif. Seule la mesure comparative montre si Code Guardian améliore le résultat du travail, et elle n'est pas encore disponible pour la 17.3. Vous trouverez plus d'informations sur le produit sur la page produit.

Questions fréquentes sur Code Guardian 17.3

Dois-je régler quelque chose pour que la mise à jour prenne effet ?

Pour le fonctionnement de base, non. Trois exceptions figurent ci-dessus : les nouveaux rapports de validation pour les migrations, la ligne de configuration pour les deux gates activables et la version de Codex.

Pourquoi ma commande de migration est-elle bloquée après la mise à jour ?

Il manque probablement à votre rapport de validation la ligne FREIGABE-FUER, ou le type de commande n'y figure pas. Les instructions ci-dessus montrent comment le recréer.

Contrôle-t-on désormais moins de choses ?

On impose moins. Les règles des douze verrous désactivés figurent toujours dans le skill, mais une infraction ne vous arrête plus. La suppression, les secrets dans un commit, la mise en production et la migration continuent de bloquer.

Où trouver les prérequis, les réglages et le paquet ?

Les prérequis et les réglages figurent dans la documentation technique. Le paquet se trouve dans le portail client. La manière dont Code Guardian reste ensuite à jour est expliquée sur provimedia.de/code-guardian/updates.

Sources

• Instructions de mise à jour publiées pour la version 17.3, versions Claude et Codex (portail client)
• Preuve de test de la version 17.3 par rapport à la v17.2 (portail client)

Mise à jour : 02.10.2026