OpenAI a discrètement publié le code source de l'interface en ligne de commande Codex Security et du SDK TypeScript. Le package public @open...
OpenAI a discrètement publié le code source de l'interface en ligne de commande Codex Security et du SDK TypeScript.
Ce package public @openai/codex-security est conçu pour aider les équipes de sécurité et d'ingénierie à :
Ce dépôt de code est publié sous licence Apache License 2.0.
Cela signifie que le code CLI et SDK est open source. Mais cela ne signifie pas que l'ensemble du service Codex Security, ses modèles sous-jacents, chaque résultat protégé, ou un accès réseau illimité sont désormais disponibles gratuitement hors ligne.
L'exécution des scans nécessite toujours un accès à Codex Security. OpenAI précise également que certains scans de l'ensemble du dépôt, les résultats protégés et les requêtes avancées de cybersécurité peuvent nécessiter une approbation via l'accès de confiance pour la cyberdéfense (Trusted Access for Cyber) .
Cette distinction est très importante :
CLI et SDK open source
≠
Modèle de sécurité à poids ouverts
≠
Accès illimité aux scans cloud
Codex Security était à l'origine un projet interne nommé Aardvark. Il est ensuite entré dans Codex en tant qu'agent de sécurité applicative en avant-première de recherche, et le nouveau package public permet désormais aux développeurs d'intégrer le scanner dans leur terminal local, leurs outils internes, les activités de scan par lots, les vérifications avant commit et les pipelines CI.
OpenAI a lancé Aardvark pour la première fois en octobre 2025, un chercheur en sécurité intelligent propulsé par GPT-5.
L'objectif de conception de ce système original était de ressembler davantage à un chercheur humain en sécurité applicative qu'à un scanner à signatures traditionnel.
Plutôt que de simplement faire correspondre le code à des modèles connus, Aardvark pouvait :
En mars 2026, OpenAI a renommé Aardvark en Codex Security et l'a intégré à Codex.
Le produit est disponible en avant-première de recherche via Codex Web pour certains abonnés ChatGPT, avec prise en charge des dépôts GitHub connectés.
La publication open source ultérieure a ajouté une couche de déploiement différente.
Les développeurs peuvent désormais installer le CLI ou importer le SDK TypeScript, tandis que l'expérience cloud hébergée Codex Security reste séparée.
Le dépôt GitHub public contient :
Le package est publié sur npm sous le nom :
@openai/codex-security
La licence Apache-2.0 de ce dépôt permet généralement l'utilisation, la modification et la redistribution dans les limites des conditions de la licence.
Cette publication ne fournit pas les poids des modèles GPT-5.6 Sol, Terra ou des modèles dédiés Codex Security.
Le scan par défaut utilise actuellement :
gpt-5.6-sol
Intensité de raisonnement : xhigh
Le CLI invoque le service d'inférence via un accès authentifié.
Le dépôt documente également des options de fournisseurs pour les modèles sélectionnés (comme OpenRouter et Fireworks), mais les flux de travail de scan Codex Security et les capacités réseau protégées peuvent toujours nécessiter une autorisation de la part d'OpenAI.
Installer le package npm ne signifie pas obtenir la permission d'exécuter chaque scan.
La documentation d'OpenAI précise :
Le code public rend les flux de travail inspectables et extensibles. Il ne supprime pas les couches de sécurité et d'autorisation entourant les usages réseau avancés.
Les agents de programmation IA génèrent et modifient des logiciels à une vitesse qui peut dépasser la capacité de revue de nombreuses organisations.
Cela crée un goulot d'étranglement en matière de sécurité.
Un produit peut passer de l'idée à l'application déployée en quelques jours, voire quelques heures, tandis que les revues de sécurité applicative traditionnelles peuvent encore dépendre de :
Le problème ne se limite pas au manque de rapports de vulnérabilités pour les développeurs.
De nombreux mainteneurs reçoivent déjà trop de rapports, notamment :
Codex Security est conçu autour de l'objectif inverse : moins de résultats, plus contextuels, accompagnés de preuves pour aider les réviseurs à décider quoi corriger.
OpenAI décrit le système comme un flux de travail de sécurité applicative en plusieurs étapes.
Codex Security commence par étudier le dépôt pour comprendre la structure liée à la sécurité du projet.
Il tente d'identifier :
Le résultat est un modèle de menaces spécifique au projet, et non une liste de contrôle générique.
Les équipes peuvent ajouter de la documentation d'architecture, des politiques de sécurité, des domaines d'intérêt et des vecteurs d'attaque connus pour améliorer ce contexte.
L'agent utilise le modèle de menaces pour juger de l'impact réel lors de l'examen du code pertinent.
Cela lui permet de raisonner sur des problèmes que les scanneurs basés sur des règles ont du mal à comprendre isolément.
Les exemples peuvent inclure :
accédant à des outils privilégiés.
Le scanner peut examiner :
Dans la mesure du possible, Codex Security tente de valider les problèmes à fort signal dans un environnement isolé.
La validation peut aider à répondre :
Cette étape vise à réduire les faux positifs.
Elle ne garantit pas que chaque résultat a été reproduit, ni qu'un scan complet prouve que le dépôt est sécurisé.
Le fichier coverage.json du scan enregistre si l'état de couverture est :
Complet
Partiel
Inconnu
Les réviseurs doivent lire les exclusions, les zones différées et les problèmes en suspens avant de considérer un scan comme une preuve d'une revue exhaustive.
Pour les résultats acceptés, Codex Security peut suggérer un correctif conçu pour s'adapter au système actuel.
L'objectif n'est pas simplement de faire taire le scanner.
Un bon correctif doit :
Éliminer ou atténuer les causes profondes.
Le scan Codex Security fournit par défaut uniquement un rapport. Les correctifs suggérés doivent toujours passer par les processus normaux de revue de code, de test et de contrôle des déploiements.
Le CLI stocke l'historique des scans et prend en charge le retour sur les découvertes.
Les réviseurs peuvent marquer une découverte comme faux positif et enregistrer la raison.
Les scans ultérieurs peuvent prendre en compte cette explication lors du réexamen du code actuel.
Cela aide le scanneur à s'adapter aux faits spécifiques du dépôt, sans supprimer définitivement des chemins de code qui pourraient devenir vulnérables à l'avenir.
OpenAI a publié plusieurs données d'adoption et de qualité issues de ses déploiements en préversion.
Ces mesures sont celles rapportées par l'entreprise et ne constituent pas des résultats de benchmarking indépendants.
OpenAI indique que, sur une période de 30 jours, Codex Security :
| Métrique | Résultat rapporté par OpenAI |
|---|---|
| Nombre de commits scannés | Plus de 1,2 million |
| Découvertes critiques | 792 |
| Découvertes à haute sévérité | 10 561 |
| Commits scannés contenant des problèmes critiques | Moins de 0,1 % |
OpenAI rapporte également que les améliorations de la version bêta :
OpenAI a ensuite indiqué que la version cloud de Codex Security disposait :
| Métrique | Résultat rapporté par OpenAI |
|---|---|
| Nombre de bases de code scannées | Plus de 30 000 |
| Nombre de commits scannés | Plus de 30 millions |
| Découvertes marquées manuellement comme corrigées | Plus de 70 000 |
| Corrections identifiées automatiquement | Plus de 500 000 |
L'ampleur est considérable, mais ces chiffres ne doivent pas être interprétés comme une comparaison contrôlée avec CodeQL, Semgrep, Snyk ou des tests d'intrusion manuels.
Ces outils fonctionnent différemment et peuvent mesurer les découvertes, les corrections et la couverture de manières différentes.
Codex Security est désormais disponible via plusieurs interfaces connexes.
| Interface | Usage principal |
|---|---|
| Plugin Codex Security | Scans et corrections interactifs dans l'application de bureau ChatGPT ou le CLI Codex |
| Workbench de sécurité | Consultation des scans enregistrés, découvertes, historique des dépôts, couverture et artefacts |
| CLI Codex Security | Workflows locaux reproductibles, en terminal, pre-commit, par lots et CI |
| SDK TypeScript | Intégration des scans et du contrôle du cycle de vie dans des applications ou outils de développement |
| Cloud Codex Security | Scan des dépôts GitHub connectés via le cloud Codex |
Le CLI public et le SDK utilisent le même flux de travail général de scanneur que le plugin, mais la disponibilité et la maturité des fonctionnalités peuvent varier entre le catalogue du plugin, le paquet CLI et l'aperçu de recherche cloud.
Les commandes suivantes suivent la documentation CLI officielle actuelle d'OpenAI.
Le CLI nécessite :
Node.js 22 ou version ultérieure
Python 3.10 ou version ultérieure
Accès à Codex Security
Le dépôt GitHub fournit actuellement une plage plus spécifique de versions Node.js prises en charge, incluant les dernières versions 22.x, 24.x et 26.x.
Vérifiez votre environnement :
node --version
python3 --version
Installez Codex Security depuis npm :
npm install @openai/codex-security
Vérifiez la version installée :
npx @openai/codex-security --version
Listez les commandes :
npx @openai/codex-security --help
Pour une utilisation locale interactive, connectez-vous avec un compte ChatGPT :
npx @openai/codex-security login
Pour les machines distantes ou sans tête :
npx @openai/codex-security login --device-auth
Pour les workflows CI ou autres flux non supervisés, fournissez une clé API via l'environnement :
export OPENAI_API_KEY=""
Ne placez pas la clé API dans le contrôle de source.
Utilisez un gestionnaire de secrets ou le système de secrets protégés de la plateforme CI.
Lorsqu'une connexion ChatGPT enregistrée et une clé API sont toutes deux disponibles, choisissez explicitement la méthode souhaitée :
npx @openai/codex-security scan . --auth chatgpt
ou :
npx @openai/codex-security scan . --auth api-key
L'authentification n'accorde pas automatiquement l'accès de confiance Cyber.
OpenAI recommande de stocker les résultats en dehors du dépôt scanné.
Les rapports peuvent contenir :
Préparez les répertoires cible et de résultats :
REPOSITORY=/chemin/vers/depot
SCAN_DIR=/chemin/hors/depot/codex-security-results
Si le répertoire d'état persistant par défaut n'est pas accessible en écriture, choisissez un autre répertoire privé :
export CODEX_SECURITY_STATE_DIR=/chemin/hors/depot/codex-security-state
Validez les chemins locaux et la configuration du scan avant de commencer le travail du modèle :
npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--dry-run
L'exécution à sec ne démarre pas Codex et ne charge pas les identifiants de scan.
Démarrez un scan de dépôt standard :
npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR"
Demandez une sortie JSON lisible par machine sur la sortie standard :
npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--json
Par défaut, Codex Security utilise actuellement :
Modèle : gpt-5.6-sol
Intensité de raisonnement : xhigh
Des configurations à moindre coût peuvent utiliser d'autres modèles et niveaux d'intensité pris en charge :
npx @openai/codex-security scan "$REPOSITORY" \
--model gpt-5.6-terra \
--effort high
Les paramètres de prise en charge suivants sont disponibles :
minimal (minimum)
low (faible)
medium (moyen)
high (élevé)
xhigh (très élevé)
Une intensité plus faible peut réduire le temps et les coûts, mais peut également diminuer la profondeur de l'examen.
Le répertoire de résultats standard peut contenir :
codex-security-results/
├── scan-manifest.json
├── findings.json
├── coverage.json
├── report.md
├── artifacts/
└── exports/
└── results.sarif
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
report.mdLe rapport principal lisible par l'humain.
findings.jsonConstats structurés, incluant la gravité, le niveau de confiance, les emplacements affectés, les preuves et les recommandations de correction.
coverage.jsonPortée de l'examen, exclusions, travaux différés, problèmes en suspens et évaluation de l'exhaustivité.
scan-manifest.jsonCibles, portée, informations sur le producteur et références aux artefacts scellés.
artifacts/Rapports de vulnérabilité, fichiers de preuve de concept ou preuves associées (le cas échéant).
Le format SARIF peut être utilisé par GitHub Code Scanning et d'autres outils de sécurité compatibles.
Les grands monorepos ne nécessitent pas nécessairement une analyse complète à chaque fois.
Sélectionnez des chemins spécifiques :
npx @openai/codex-security scan "$REPOSITORY" \
--path services/billing \
--path packages/auth
Cette approche est particulièrement utile lorsqu'une publication affecte des services ou des frontières de sécurité spécifiques.
Analysez les modifications validées entre la révision de base et HEAD :
npx @openai/codex-security scan "$REPOSITORY" \
--diff origin/main \
--head HEAD
Le paramètre de référentiel doit pointer vers la racine de l'arbre de travail Git, et les révisions requises doivent exister localement.
Analysez les modifications indexées et non indexées par rapport à HEAD :
npx @openai/codex-security scan "$REPOSITORY" \
--working-tree \
--base HEAD
Cette approche est particulièrement utile avant de créer une demande de tirage ou de valider des modifications sensibles à la sécurité.
Lorsqu'une analyse ordinaire ne suffit pas, lancez un examen plus complet :
npx @openai/codex-security scan "$REPOSITORY" \
--mode deep
Le mode approfondi prend plus de temps et peut consommer davantage de ressources du modèle.
La documentation actuelle d'OpenAI indique qu'elle prend en charge les cibles de référentiel et de chemin, mais pas les cibles diff ou working-tree.
Fournissez de la documentation interne pour aider l'agent à comprendre correctement le système :
npx @openai/codex-security scan "$REPOSITORY" \
--knowledge-base /path/to/architecture.md \
--knowledge-base /path/to/security-policies
Un contexte utile peut inclure :
N'incluez pas inutilement d'informations confidentielles.
Ces fichiers font partie d'un flux de travail d'analyse sensible à la sécurité et doivent respecter les règles appropriées de conservation et de contrôle d'accès.
Définissez un plafond de coût estimé du modèle en dollars :
npx @openai/codex-security scan "$REPOSITORY" \
--max-cost 5
Les demandes déjà en cours peuvent se terminer après l'atteinte du plafond, donc le montant final peut dépasser le seuil.
Lorsqu'une analyse limitée par le coût s'arrête, Codex Security conserve les résultats déjà obtenus.
Les résultats partiels ne doivent pas être considérés comme une couverture complète du référentiel.
Installez le crochet Git fourni :
npx @openai/codex-security install-hook
Ce crochet analyse les modifications indexées et non indexées avant la validation.
OpenAI indique qu'il bloque :
Il ne remplace pas les scripts pré-validation existants.
Les équipes doivent examiner comment il interagit avec les performances locales, les droits d'accès des développeurs, les coûts du modèle et les crochets de lint ou de test existants avant de l'activer à l'échelle de l'organisation.
Commencez par vérifier la CLI GitHub :
gh auth login
Lancez le processus interactif de découverte de référentiels :
npx @openai/codex-security bulk-scan
Le processus interactif actuel exclut les référentiels archivés et les forks, et demande une confirmation avant l'analyse.
Utilisez une liste CSV préparée pour des campagnes d'analyse reproductibles :
npx @openai/codex-security bulk-scan repositories.csv \
--output-dir /path/outside/repositories/security-scans \
--workers 4
Réexécuter la même commande permet de reprendre une campagne d'analyse sans réanalyser les référentiels disposant déjà d'artefacts de résultats complets.
Le référentiel public contient des ressources Docker et Compose.
Avec un accès au compte contenant les images requises et l'environnement, un exemple de commande groupée est :
docker compose run --rm codex-security \
bulk-scan /input/repositories.csv \
--output-dir /output \
--workers 4
OpenAI recommande :
La conteneurisation réduit une partie de l'exposition de l'hôte, mais ne rend pas les analyses de sécurité autorisées sans risque.
Listez les analyses précédentes d'un référentiel :
npx @openai/codex-security scans list "$REPOSITORY"
Inspectez une analyse enregistrée :
npx @openai/codex-security scans show SCAN_ID
Marquez un constat déjà examiné comme faux positif :
npx @openai/codex-security findings false-positive FINDING_OCCURRENCE_ID \
--reason "Cette route vérifie déjà les autorisations"
Réexécutez une analyse enregistrée avec ses paramètres d'origine :
npx @openai/codex-security scans rerun SCAN_ID
Faites correspondre les constats par cause racine :
npx @openai/codex-security scans match
PREVIOUS_SCAN_ID CURRENT_SCAN_ID
Comparez les résultats de scan :
```Bash
npx @openai/codex-security scans compare PREVIOUS_SCAN_ID CURRENT_SCAN_ID
La comparaison peut classer les constatations comme :
Lorsque les scans ultérieurs ne couvrent pas la zone concernée, les constatations manquantes restent dans un état inconnu.
Le même paquet npm contient un SDK TypeScript en module ECMAScript.
Il nécessite Node.js 22 ou version ultérieure côté serveur, et Python 3.10 ou version ultérieure pour les scans.
L'intégration de base est la suivante :
import { CodexSecurity } from "@openai/codex-security";
const security = new CodexSecurity();
try {
const result = await security.run("/chemin/vers/depot", {
outputDir: "/chemin/hors/depot/resultats",
});
console.log(result.reportPath);
console.log(result.coverage.completeness);
console.log(result.findings.findings.length);
} finally {
await security.close();
}
Le SDK prend en charge les flux de travail de longue durée grâce aux fonctionnalités suivantes :
Les applications réutilisables doivent créer un client, exécuter les scans nécessaires, puis fermer le client pour libérer l'environnement d'exécution isolé.
Le guide CI officiel d'OpenAI démontre l'utilisation de GitHub Actions pour les scans de pull requests.
Le modèle recommandé est le suivant :
L'exemple officiel verrouille une version de paquet spécifique disponible au moment de la publication. Les équipes doivent mettre à jour intentionnellement cette version après avoir consulté les notes de version, plutôt que d'utiliser automatiquement des secrets de dépôt pour exécuter des outils de sécurité non examinés.
Une représentation concise de l'étape de scan principale est la suivante :
- name: Scanner les modifications de la pull request
env:
OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
BASE_SHA: ${{ github.event.pull_request.base.sha }}
HEAD_SHA: ${{ github.event.pull_request.head.sha }}
SCAN_DIR: ${{ runner.temp }}/codex-security-results
run: |
set -euo pipefail
BASE_REVISION="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
"$CODEX_SECURITY_BIN" scan . \
--diff "$BASE_REVISION" \
--head "$HEAD_SHA" \
--auth api-key \
--output-dir "$SCAN_DIR" \
--json > "$RUNNER_TEMP/codex-security.json"
Cet extrait suppose que l'exécuteur a installé et vérifié le CLI, qu'il a vérifié la tête de la pull request avec l'historique complet, et que CODEX_SECURITY_BIN est défini.
Pour les flux de production, utilisez le guide CI officiel complet, y compris
les actions épinglées, l'export SARIF, les permissions, la conservation des artefacts et les vérifications de sécurité des branches.
Codex Security ne vise pas à remplacer tous les contrôles de sécurité existants.
Il peut compléter les outils suivants :
Son avantage unique réside dans sa capacité à raisonner sur le contexte à travers la structure du dépôt et l'intention du système.
Un écosystème de sécurité mature peut utiliser des scanners déterministes pour les modèles connus à volume élevé, et des scanners intelligents pour la logique multi-fichiers, l'analyse d'exploitabilité, les preuves et les recommandations de correction.
Aucun scanner ne peut prouver l'absence de toutes les vulnérabilités dans une base de code réelle arbitraire.
Une couverture partielle ou inconnue rend cette limitation encore plus importante.
Certaines constatations peuvent être testées dans un environnement isolé.
D'autres dépendent de :
Une constatation sans preuve automatisée n'est pas automatiquement un faux positif, et une preuve validée ne révèle pas toutes les variantes de cette vulnérabilité.
Le modèle peut mal interpréter l'architecture, surestimer l'impact, proposer des correctifs incomplets ou introduire des régressions.
Les responsables de la sécurité doivent examiner les preuves et les propositions de correction.
Le code source du paquet est public, mais le scan par défaut n'est pas un binaire statique local entièrement indépendant de l'accès au raisonnement.
L'utilisation du modèle peut engendrer des considérations de coût, de traitement des données et d'autorisation.
Le répertoire de résultats peut être plus sensible que les sorties de build ordinaires.
Ne téléversez pas de constatations détaillées, de fichiers de preuve de concept ou d'extraits de code source vulnérables dans des artefacts publics.
Utilisez l'outil uniquement sur des dépôts et systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite d'évaluation.
Les contrôles d'accès d'OpenAI ne remplacent pas l'autorisation légale.
Le plus grand avantage conceptuel de Codex Security est aussi une exigence pratique.
L'agent a besoin d'un contexte précis.
Le dépôt seul peut ne pas expliquer :
Un mauvais contexte peut conduire à des constatations de mauvaise qualité.
Les équipes doivent considérer les modèles de menace modifiables et les bases de connaissances comme des actifs de sécurité de première classe, et non comme des décorations de prompt optionnelles.
Codex Security est l'agent de sécurité applicative d'OpenAI qui découvre, valide, priorise et aide à corriger les vulnérabilités. Issu du projet interne Aardvark, il est désormais disponible.
Il est implémenté via des plugins, un CLI, un SDK TypeScript et des flux de travail cloud connectés aux dépôts.
Le CLI et le SDK TypeScript sont publiés sur GitHub sous licence Apache 2.0.
Publication sous licence publique. Le modèle OpenAI sous-jacent, les services cloud hébergés, les résultats de détection protégés et l'accès à la cybersécurité sans restriction ne sont pas publiés en tant que composants open source ou à poids ouvert.
Tout le monde peut accéder aux packages publics, mais l'exécution des analyses nécessite un accès Codex Security. Certaines analyses de dépôt entier ou capacités réseau avancées peuvent également nécessiter un « Accès de confiance pour la cybersécurité » (Trusted Access for Cyber).
La documentation actuelle de la CLI indique que les analyses utilisent par défaut GPT-5.6 Sol avec un niveau d'effort de raisonnement xhigh. Les utilisateurs peuvent choisir d'autres modèles et niveaux d'effort pris en charge, et le dépôt public documente également des configurations tierces sélectionnées.
Oui. La CLI peut analyser les modifications validées entre la révision de base et la révision de tête, ce qui la rend adaptée aux flux de travail de demandes de tirage. OpenAI fournit également un guide officiel pour GitHub Actions, avec prise en charge de l'exportation SARIF et de la conservation des artefacts.
Il peut proposer des suggestions de correctifs limitées et aider à vérifier que les modifications résolvent un résultat de détection. Les analyses ne génèrent par défaut que des rapports ; les humains doivent examiner, tester et approuver les correctifs avant toute fusion ou déploiement.
Le dépôt contient des ressources Docker et Docker Compose pour les analyses par lots non interactives. OpenAI recommande un stockage persistant privé, une gestion des secrets, des fonctionnalités d'isolation Linux prises en charge et, en option, un renforcement AppArmor.
Non. La couverture peut être complète, partielle ou inconnue, et aucun analyseur automatisé ne peut garantir l'absence de vulnérabilités dans une application complexe. Utilisez Codex Security comme un élément d'un programme de développement sécurisé plus large.
OpenAI a ouvert le code de la CLI et du SDK TypeScript de Codex Security, offrant aux développeurs une base publique sous licence Apache-2.0 pour l'analyse de dépôts, la revue de modifications, l'historique d'analyses, la vérification de correctifs, les activités par lots, l'exportation SARIF, les contrôles CI et les intégrations de sécurité personnalisées.
Cet agent diffère des analyseurs de motifs de base : il construit le contexte du dépôt et un modèle de menace, recherche des vulnérabilités dans ce contexte, valide autant que possible les problèmes suspects et propose des correctifs limités pour examen humain.
Cette version ne constitue pas un modèle de sécurité local sans restriction. L'exécution des analyses nécessite toujours un accès d'inférence autorisé, et certains flux de travail avancés de cybersécurité peuvent nécessiter un « Accès de confiance pour la cybersécurité ». Les résultats de détection sensibles et les extraits de code source exigent également des contrôles prudents de stockage et de conservation.
Codex Security est plus utile dans le cadre d'un programme de sécurité applicative en couches — et non comme preuve qu'un dépôt est exempt de vulnérabilités.
Le changement réel est que les revues de sécurité peuvent désormais se rapprocher de la vitesse du développement assisté par IA, à condition que les équipes appliquent strictement l'autorisation, la modélisation des menaces, la validation et l'approbation humaine dans leurs processus.
Partez d’une phrase et obtenez un site complet en quelques minutes.
