Kortix

Une phrase pour présenter

Kortix est un système de gestion d’agents IA destiné aux entreprises et aux équipes, qui regroupe des agents intelligents, des compétences, une mémoire partagée, des connecteurs, des déclencheurs et un environnement de exécution au sein de projets soumis à un contrôle de version.

Présentation des outils

Kortix insiste sur le concept de « Company as Code » : chaque projet utilise un répertoire Git comme registre permanent des configurations et des connaissances, les agents exécutent des tâches dans des environnements de calcul indépendants et soumettent les résultats sous forme de demandes de modification. Les humains peuvent d’abord examiner les différences avant de décider s’il convient de les fusionner.

Les projets initiaux sont bien connus grâce à l’assistant IA universel Suna ; l’adresse du dépôt officiel conserve encore le nom Suna, mais les produits, la documentation et les descriptions de code ont tous été renommés pour désigner le Kortix AI Management System. Les interfaces, les méthodes de déploiement et les tarifs présentés dans les anciens tutoriels peuvent être obsolètes.

Architecture centrale

Fonction principale

Company as Code

Les définitions d’agents, les compétences, la mémoire organisationnelle, la configuration des connecteurs et les déclencheurs peuvent tous être enregistrés sous forme de fichiers texte dans le même dépôt Git. L’équipe peut rechercher, comparer, examiner et revenir en arrière sur ces modifications, au lieu de ne pas dépendre que des paramètres stockés dans une base de données fermée.

Agents multiples et compétences partagées

L’équipe peut créer des agents différents pour les tâches de vente, d’ingénierie, de finance, d’opérations ou de données, et réutiliser des méthodes de travail standard grâce à des fichiers de compétences. Chaque agent peut disposer de modèles, d’outils, de connecteurs, de clés et de droits d’exécution différents.

Mémoire de l’entreprise

La mémoire accumule les faits commerciaux, les processus et l’expérience sous forme de fichiers de projet, et peut être consultée avec l’historique Git. La mémoire à long terme aide à maintenir la cohérence dans les tâches répétitives, mais des informations erronées ou obsolètes peuvent également influencer les décisions ultérieures.

Agent Computer

Chaque session lance une sandbox Linux indépendante, clone le répertoire du projet et crée une branche exclusive. L’agent peut installer des dépendances, exécuter des programmes, traiter des fichiers et appeler des outils ; une fois la sandbox terminée, seules les modifications soumises à Git sont conservées.

Connecteurs et outils

La plateforme affiche plus de 3000 connexions d’applications et prend en charge MCP, OpenAPI, Postman, GraphQL ainsi que des interfaces de demande web générales. Les connecteurs conviennent pour se connecter à Slack, GitHub, Notion, les systèmes CRM, les solutions de paiement et les systèmes de tickets.

Déclencheur automatisé

Les tâches peuvent être déclenchées par une conversation manuelle, un planning programmé ou un Webhook signé, et entrent toutes dans le même processus d’exécution de session. Elles conviennent aux rapports quotidiens, au suivi en temps réel, à la synchronisation des données, à la détection des erreurs et à la maintenance périodique du contenu.

Demande de modification

Les modifications des fichiers de l’Agent restent d’abord dans la branche de session, et les ajouts, suppressions et modifications sont présentés via des demandes de modification. Par défaut, l’Agent ne peut soumettre que des modifications ; la fusion relève d’une autorisation distincte.

CLI et interfaces de développement

Kortix propose des outils en ligne de commande, des interfaces REST et des SDK permettant de créer des projets, de lancer des sessions, de consulter l’état de fonctionnement, de gérer les connecteurs et de traiter les demandes de modification. Les développeurs peuvent également intégrer des sessions d’Agent dans leurs propres applications.

Comment une mission est-elle exécutée

1. L’équipe définit dans le dépôt Git la liste des projets, les Agents, les compétences, la mémoire et l’environnement de exécution.
2. L’administrateur connecte le modèle, l’application métier et les clés nécessaires, et définit la portée des autorisations de l’agent.
3. Les utilisateurs lancent des tâches depuis des pages web, Slack, la CLI, l’API, des compteurs à retardement ou des Webhooks.
4. La plateforme crée une sandbox indépendante et une branche Git du même nom pour cette session.
5. L’agent OpenCode lit les tâches, planifie les étapes et appelle les outils autorisés.
6. Les opérations externes nécessitant une approbation seront suspendues et les paramètres spécifiques affichés.
7. L’agent soumet les fichiers et les configurations à conserver à la branche de session.
8. Le système crée une demande de modification et affiche les différences par rapport à la branche par défaut.
9. Le responsable examine les résultats, demande des modifications, clôture ou fusionne les changements.
10. Le contenu fusionné devient l’état du nouveau projet pour les sessions ultérieures.

Différences entre agent, compétence et mémoire

Soutien aux modèles et BYOK

Kortix n’est pas lié de manière fixe à un seul modèle ; l’utilisateur peut choisir un modèle en fonction de l’Agent, de la session ou du message. Il prend en charge les fournisseurs de modèles majeurs, des endpoints compatibles personnalisés, ses propres clés API ou une abonnement existant à ChatGPT.

Les modèles, les quotas, les régions et les conditions relatives aux données varient selon les méthodes d’accès. Avant le lancement, il convient de valider le modèle sélectionné, le dialecte API, la longueur du contexte, les appels d’outils et la facturation à l’aide de tâches réelles, plutôt que de se contenter de vérifier si la clé permet une connexion.

Connecteur et agent de certificats

Les identifiants des connecteurs tiers sont stockés sur le serveur ; la sandbox de l’agent ne possède généralement qu’un token Kortix à portée restreinte, qui est ensuite utilisé par l’agent de plateforme pour appeler les outils réels. Cela diminue les chances que le token OAuth original entre dans une sandbox générique.

• Le répertoire des applications couvre les outils de collaboration, de code, de CRM, financiers et de documents les plus courants.
• Les systèmes personnalisés peuvent être connectés via MCP ou une API.
• Les connecteurs doivent être autorisés séparément pour la zone de travail et l’Agent.
• Des stratégies différentes doivent être définies pour la lecture, l’écriture et les opérations destructives.
• Les conditions des paramètres de l’outil peuvent limiter les destinataires, les comptes ou les ressources cibles.
• Les pages web et documents externes peuvent contenir du contenu d’injection de suggestions.
• Les conditions, les règles de limitation du débit et les règles de réservation propres au service de connexion restent en vigueur.
• Après la suppression des identifiants en amont, il faut vérifier que le token Kortix ne permet plus non plus d’accéder.

Gestion des clés

La clé du projet est chiffrée statiquement avec AES-256-GCM et isolée par une clé dérivée du projet. Les clés autorisées en tant que variables d’environnement de exécution sont écrites dans un système de fichiers temporaire au démarrage de la sandbox, ce qui permet à l’Agent d’accéder à leur valeur réelle lorsqu’il utilise des outils.

Lors de la première mise à jour de la liste des autorisations des Agents pour un projet, les autres Agents non listés perdent l’accès aux clés du projet, ce qui constitue un changement important en matière de gouvernance. La configuration de production doit lister tous les Agents ayant besoin de clés, et les autorisations réelles doivent être vérifiées au moyen de sessions de test.

Approbation de l’appel d’outil

La stratégie de projet peut définir les appels d’outils pour une exécution directe, une demande d’approbation ou un blocage, et permettre une correspondance en fonction du chemin de l’outil et des paramètres. Une stratégie par défaut appropriée peut faire en sorte que la lecture s’exécute automatiquement, tandis que l’envoi, le paiement, la suppression et l’écriture de production sont soumis à une confirmation manuelle.

• Utiliser le modèle de risque comme stratégie par défaut explicite.
• Définir des conditions pour l’envoi d’e-mails en fonction du nom de domaine du destinataire.
• Les outils de paiement et de facturation exigent par défaut une approbation.
• Interdiction directe ou confirmation secondaire pour la suppression, le déploiement et les modifications de droits.
• Chaque approbation affiche l’objectif complet et les paramètres clés.
• Ne pas utiliser des autorisations permanentes qui couvrent toute la session.
• Lorsque les conditions des paramètres ne peuvent pas être analysées, il faut traiter cela comme une erreur et fermer.
• Tester régulièrement la stratégie avec des entrées malveillantes et des paramètres incorrects.

Les projets anciens sans bloc de stratégie peuvent continuer à utiliser des valeurs par défaut historiques plus souples. Lors du transfert de projets existants, il est nécessaire de vérifier explicitement le mode par défaut ; on ne peut pas supposer que tous les anciens Agents sont sous contrôle simplement parce que la nouvelle interface dispose d’une fonction d’approbation.

Isolation des sessions

Une session correspond à un sandbox, un système de fichiers et une branche Git, ne partageant pas le répertoire de exécution avec d’autres sessions. Le sandbox a une durée de vie définie et peut être détruit et reconstruit en cas d’installation incorrecte ou de modifications destructrices.

La force d’isolation dépend du fournisseur de calcul réellement choisi ; on ne peut pas qualifier toutes les sessions Kortix de mini-machines virtuelles. Lors de l’achat, il convient de vérifier le site de fonctionnement, l’isolation des locataires, les sorties réseau, les images, les journaux et les mécanismes de destruction.

Demandes de modification et vérification manuelle

Chaque session fonctionne dans une branche indépendante ; toute modification de code, d’agent, de compétence, de mémoire ou de liste de projets doit être introduite dans la branche par défaut via une demande de modification. Le système vérifie les différences, les relations de soumission, la validité de la configuration et les conflits de fusion.

1. L’agent termine son travail dans la branche de session et crée des commits petits et vérifiables.
2. Après avoir soumis la poussée, créez une demande de modification en remplissant le titre et la description.
3. Le responsable consulte la liste des fichiers, ajoute ou supprime des lignes et examine les résultats de l’exécution.
4. Toute modification concernant les stratégies, les clés ou les droits des agents fait l’objet d’une vérification supplémentaire.
5. Lorsqu’une correction est nécessaire, demander une modification et laisser la session initiale continuer son traitement.
6. Vérifier les conflits de prévisualisation avant la fusion et valider la liste des projets.
7. Seules les personnes ou comptes de service ayant des droits d’intégration indépendants peuvent effectuer l’intégration.
8. Observer l’impact du nouvel état après la fusion sur les sessions ultérieures et l’automatisation.

Canaux d’accès

Scénarios d’automatisation

• Rassembler les journaux d’erreurs chaque jour et proposer des corrections de code.
• Organiser les leads de vente et générer des drafts de contact personnalisés.
• Vérifier les champs CRM et gérer le pipeline de vente.
• Rapprochement, suivi des justificatifs manquants et établissement de rapports financiers.
• Surveiller les performances de la recherche et proposer des mises à jour de contenu.
• Regrouper les retours des utilisateurs pour définir des modifications visant à améliorer le produit.
• Interroger le data warehouse et publier périodiquement les indicateurs de performance.
• Gérer les arrivées, départs et demandes de visite des employés.
• Organiser les questionnaires de sécurité, les preuves de conformité et les documents d’audit.
• Envoyer un e-mail ou mettre à jour le système externe après approbation manuelle.

Mode self-hébergé

Kortix permet d’exécuter le plan de contrôle sur des ordinateurs portables, des VPS, des VPC d’entreprise ou des réseaux locaux, et utilise Docker Compose pour déployer des composants tels que des pages web, des API, des mécanismes d’authentification, PostgreSQL, un stockage de fichiers et des passerelles. Les bases de données, les fichiers, les dépôts de projets, les politiques et les clés de plateforme sont stockés sur des disques gérés par l’utilisateur.

L’autogestion classique ne signifie pas être complètement hors ligne ; par défaut, le sandbox de l’agent est toujours exécuté par des fournisseurs de calcul tels que Daytona, Platinum ou E2B, et les images doivent également être téléchargées depuis le registre. Un réseau isolé ou un environnement à couche d’air relève d’une implémentation entreprise qui nécessite une planification distincte.

Étapes de mise en œuvre auto-hébergée

1. Déterminer s’il s’agit seulement d’une évaluation, de la production de VPC ou d’un déploiement avec isolation stricte.
2. Préparer Docker, le nom de domaine, le chiffrement des transferts, le disque et l’environnement de sauvegarde.
3. Installez Kortix CLI et lancez le guide de configuration auto-hébergée.
4. Définir l’adresse de rappel et les droits de création pour les administrateurs et les organisations.
5. Sélectionnez un fournisseur de sandbox et configurez les clés correspondantes.
6. Se connecter au service de catalogue d’applications et à la fenêtre de mise à jour automatique selon les besoins.
7. Configurer Git, les modèles, les membres et les permissions de projet dans la page web.
8. Créer un projet de test et valider les sessions, les branches et les demandes de modification.
9. Faire une sauvegarde du répertoire PostgreSQL, des répertoires de fichiers et de la configuration de l’environnement de l’instance.
10. Tester le renouvellement des clés, la récupération des services, la mise à niveau de version et le rollback.
11. Se connecter au système d’exploitation en production uniquement après avoir passé l’inspection de sécurité.

Comparaison entre Cloud et hébergement self-hosté

Prix et forfaits

Les informations sur les prix ont été vérifiées le 23 août 2026 ; les montants réels, les taxes, les taux de change et les remises peuvent varier. Les données finales seront celles affichées sur la page de paiement.

Kortix utilise un mode de facturation Cloud basé sur le nombre de places et le volume d’utilisation, avec un pool de points commun aux modèles de calcul et aux modèles de hébergement optionnels. Lorsque des clés de modèle sont fournies ou qu’une abonnement ChatGPT existant est utilisé, les frais de modèle ne sont pas déduits des points de la sandbox gratuite.

Chaque place dans une équipe comprend 2500 points, équivalant à 25 dollars en crédits d’utilisation. Seuls les points utilisés pour le calcul du Agent Computer par défaut permettent d’exécuter environ 125 heures ; l’utilisation de modèles gérés consomme également ces points du pool.

Facturation Agent Computer

Le calcul se fait en fonction des ressources et du temps, et l’arrêt automatique permet de réduire les coûts d’inactivité. La consommation réelle est également influencée par la taille de la sandbox, le nombre de sessions simultanées, le stockage, la durée de fonctionnement et les tokens des modèles hébergés.

Contrôle des coûts

• Préférez définir un temps d’exécution maximal pour la tâche.
• Activer l’arrêt automatique en cas d’inactivité et vérifier le déclencheur d’arrêt.
• Surveiller séparément la facture du modèle et l’intégration de sandbox.
• Définir des budgets pour les agents et les équipes pour les modèles à coût élevé.
• Limiter le nombre de sessions simultanées pour les tâches sans surveillance.
• Stocker les données stables en cache pour éviter des téléchargements et installations répétés.
• Fixer des limites pour les boucles, les tentatives de réessai et les tempêtes Webhook.
• Calculer le coût par tâche et le taux de réussite par projet.
• Définir à l’avance des alertes pour insuffisance de points et pour dépassement des limites du modèle.

Sécurité et permissions

• Chaque session utilise un sandbox indépendant et une branche Git.
• La clé de projet est chiffrée à l’aide d’une clé dérivée du projet.
• Les identifiants d’origine du connecteur n’entrent généralement pas dans l’ordinateur de l’agent.
• Les droits de l’agent et du déclencheur déterminent conjointement la livraison de la clé.
• Les appels d’outils peuvent être configurés pour être exécutés, approuvés ou bloqués.
• La fusion est une autorisation indépendante et est par défaut refusée aux Agents.
• Les opérations de compte et d’agent génèrent des événements d’audit.
• Enterprise peut lire, exporter ou envoyer des enregistrements d’audit vers un SIEM.
• SAML, SCIM, les rôles et groupes personnalisés appartiennent à Enterprise.

Les certifications SOC 2 de type I et de type II sont actuellement toutes deux indiquées comme en cours ; il ne peut donc pas être affirmé que des rapports ont déjà été obtenus. Kortix a clairement indiqué ne pas disposer pour l’instant de la certification ISO 27001 ou HIPAA, et les achats soumis à réglementation doivent encore faire l’objet d’une évaluation de sécurité propre.

Confidentialité et gouvernance des données

Les entrepôts de projets, les fichiers, les conseils, les connecteurs métier et les demandes de modèles peuvent contenir des informations d’entreprise hautement sensibles. La version hébergée, le plan de contrôle auto-hébergé, les fournisseurs de sandbox, les fournisseurs de modèles et les applications tierces constituent respectivement différentes étapes du traitement des données.

Enterprise propose une option DPA, mais les sous-processedurs spécifiques, les régions des données, les engagements de formation et la durée de conservation doivent être confirmés dans le contrat actuel ainsi que dans les documents de confidentialité. Le plan de contrôle auto-hébergé ne peut pas non plus éliminer automatiquement les flux de données provenant des sandbox externes, des modèles et des connecteurs.

Logiciels libres et licences

Kortix met à disposition le dépôt principal complet de manière publique, permettant la consultation, la modification et l’hébergement propre, mais utilise actuellement la Elastic License 2.0. Cette licence comporte des restrictions commerciales claires qui interdisent d’offrir les fonctionnalités principales du logiciel via un hébergement tiers ou des services hébergés.

Les fabricants utilisent le terme « open-source » pour décrire leurs produits, mais la Elastic License 2.0 est généralement classée comme une licence permettant l’accès au code source, et non comme une licence open-source traditionnelle approuvée par l’OSI. Le catalogue doit indiquer simultanément que le code est public, qu’il peut être hébergé soi-même, ainsi que les restrictions liées aux services d’hébergement.

À qui s’adresse-t-il

• Équipe souhaitant gérer de manière unifiée plusieurs agents d’entreprise.
• Organisations souhaitant intégrer les agents, les compétences et la mémoire dans une gouvernance Git.
• Utilisateurs qui ont besoin d’un Agent pour exécuter des programmes et traiter des fichiers dans un environnement Linux réel.
• Les entreprises qui souhaitent utiliser différents modèles tout en conservant la capacité BYOK.
• Équipes ayant besoin de se connecter à un grand nombre de SaaS, MCP et d’API internes.
• Les organisations qui souhaitent déclencher le même flux de travail via Slack, la CLI, l’API et des compteurs temporels.
• Les entreprises ayant besoin d’une VPC, d’un plan de contrôle local ou self-hébergé.
• Équipe technique disposée à mettre en place une gouvernance pour l’approbation, les clés, les sandbox et les demandes de modification.

Avantages du produit

• Regrouper l’agent, les compétences, la mémoire et les connecteurs dans le même projet.
• La structure Git permet de comparer, d’examiner et de revenir en arrière sur les configurations et les résultats.
• Chaque session dispose d’un sandbox et d’une branche indépendants, ce qui réduit la contamination mutuelle.
• La demande de modification intègre le travail de l’IA à une vérification manuelle.
• Prend en charge plusieurs modèles, BYOK et des endpoints compatibles.
• Le connecteur couvre le répertoire des applications, MCP et divers protocoles API.
• Les pages web, Slack, la CLI, l’API et les déclencheurs automatiques partagent un modèle d’exécution commun.
• Le plan de contrôle peut fonctionner sur sa propre infrastructure.
• La version gratuite peut être utilisée pour des vérifications de petite envergure.
• Le prix du siège inclut des points d’utilisation de sandbox quantifiables.

Principales restrictions

• Le entrepôt principal utilise la Elastic License 2.0 et restreint les services de hébergement tiers.
• Par défaut, le plan de contrôle auto-hébergé dépend toujours d’un fournisseur externe de sandbox.
• Une mise en œuvre avec isolation complète ou espace d’air nécessite une planification distincte.
• Team facture à la fois en fonction des places et des points d’utilisation.
• Le modèle de gestion et le pool de points de partage de calcul nécessitent un suivi détaillé des coûts.
• L’agent peut exécuter du code et effectuer des opérations externes ; une configuration incorrecte peut avoir des conséquences réelles.
• Les projets anciens sans bloc de stratégie explicite peuvent conserver des valeurs par défaut plus souples.
• La clé de fonctionnement autorisée sera introduite dans le sandbox avec des valeurs provenant de l’environnement réel.
• Les connecteurs externes et les modèles introduisent des risques indépendants en matière de confidentialité et de sécurité.
• Le niveau de maturité des canaux tels que Microsoft Teams, l’e-mail et la voix est inégal.
• Le rapport SOC 2 est encore en cours d’élaboration ; aucune certification ISO 27001 ou HIPAA n’est détenue.
• Les modèles complexes de Git, de conteneurs, de clés et de permissions nécessitent une maintenance par l’équipe technique.

Liste de mise en œuvre et d’acceptation

1. Choisir la première tâche métier dont les résultats sont vérifiables et qui fait l’objet d’un faible nombre d’écritures externes.
2. Définir le dépôt de projets, l’Agent, les compétences, la mémoire et le responsable.
3. Confirmer les limites de déploiement Cloud, auto-hébergé, VPC ou isolé.
4. Analyser un par un les flux de données du modèle, du sandbox et du connecteur.
5. Définir des stratégies d’outils par défaut et des conditions de paramètres claires.
6. Accordez à l’agent uniquement les connecteurs et les clés nécessaires à la tâche.
7. Il est interdit à l’agent de fusionner directement la branche par défaut ou d’exécuter des opérations à haut risque.
8. Les tests mettent en évidence l’injection de suggestions, les paramètres incorrects des outils, ainsi que les coûts liés aux boucles et à la concurrence.
9. Vérifier la destruction du sandbox, le renouvellement des clés, ainsi que les sauvegardes et la restauration.
10. Statistiques sur le taux de réussite, le taux de modification manuelle, le temps d’exécution et le coût total.
11. Vérifier les licences, le DPA, les sous-traitants et les matériaux sécurisés.
12. Augmenter les droits de déclenchement automatique et d’écriture uniquement après validation à petite échelle.

Questions fréquentes

Que fait principalement Kortix ?

Il aide l’équipe à gérer de manière centralisée les agents, compétences, mémoires, connecteurs et automatisations de l’entreprise, et fait en sorte que chaque tâche s’exécute sur un ordinateur d’agent indépendant, pour finalement livrer les résultats via des demandes de modification Git.

Quelle est la relation entre Kortix et Suna ?

Suna était la marque de l’assistant IA universel utilisé dans les premières phases de ce projet, et le chemin du stockage conserve encore le nom Suna. Le produit actuel a été étendu et est désormais appelé de manière unifiée Kortix AI Management System.

Kortix est-il gratuit ?

Cloud Free comprend 200 points de calcul en sandbox et 1 projet par mois ; les modèles hébergés ne sont pas pris en charge par ces points gratuits. Le logiciel peut également être auto-hébergé gratuitement, mais les coûts d’infrastructure, de sandbox et de modèles incombent à l’utilisateur.

Comment Team facture-t-il ?

Team coûte 40 dollars par siège et par mois ; chaque siège comprend 2500 points de pool. Ces points sont utilisés pour l’Agent Computer ainsi que pour les modèles de hébergement optionnels, et il est nécessaire de recharger en cas de dépassement.

Combien de temps durent 200 points gratuits ?

Par défaut, l’ordinateur agent avec 2 cœurs CPU, 4 Go de mémoire et 20 Go d’espace de stockage consomme environ 20 points par heure ; il est donc utilisé pendant environ 10 heures uniquement pour les calculs. Des ressources plus importantes et d’autres facteurs d’utilisation modifieront les résultats.

Kortix est-il un véritable logiciel open source ?

Le code est public et peut être modifié et auto-hébergé, mais il est soumis à la Elastic License 2.0, qui interdit de proposer les fonctionnalités principales en tant que service hébergé par un tiers. Une description plus précise serait que le code source est disponible et permet l’auto-hébergement, plutôt qu’il s’agisse d’un open source souple.

Le self-hosting peut-il être complètement hors ligne ?

L’autogestion classique en un clic nécessite toujours de télécharger l’image et de configurer un fournisseur de sandbox externe. Les topologies entièrement hors ligne, à air gap ou avec sandbox local exigent une planification distincte pour le déploiement en entreprise.

L’agent peut-il fusionner automatiquement ses modifications ?

Par défaut, c’est impossible : l’agent peut soumettre une branche et créer une demande de modification, mais la fusion est une opération indépendante qui est par défaut rejetée. Même si l’administrateur autorise activement la fusion automatique, il reste responsable des risques associés.

Résumé

Kortix convient aux équipes qui souhaitent gérer de manière unifiée plusieurs agents d’entreprise, des compétences partagées, une mémoire organisationnelle et des connecteurs métier, tout en contrôlant le processus de livraison à l’aide de Git et d’environnements de calcul isolés. Les modèles multiples, BYOK, Agent Computer, les demandes de modification et l’autogestion constituent ses principales particularités.

Avant de l’adopter, il est nécessaire de vérifier spécifiquement les restrictions de hébergement de la Elastic License 2.0, la dépendance du self-hosting vis-à-vis des sandbox externes, le coût par utilisateur et par volume d’utilisation, ainsi que les droits par défaut et les limites d’accès aux clés réelles dans le sandbox. Ce n’est qu’en configurant correctement l’approbation, les clés, le réseau et l’audit des modifications que l’on peut maîtriser les capacités d’automatisation d’entreprise de la plateforme.