Kodus

Une phrase pour présenter

Kodus est une plateforme open source d’audit de code IA destinée aux équipes de développement logiciel ; son premier agent, Kody, peut analyser les modifications de code dans les demandes de pull, fournir du contexte supplémentaire et donner des recommandations exécutables.

Présentation des outils

Kody intègre l’audit automatisé dans le flux de travail Git existant de l’équipe, en se concentrant sur la détection des défauts potentiels, des risques de sécurité, des problèmes de performance, de la qualité du code et des écarts par rapport aux normes de l’équipe. Il peut être utilisé en mode hébergé ou déployé sur sa propre infrastructure.

La plateforme n’est pas liée à un modèle unique de manière fixe et utilise par défaut le mode BYOK. L’équipe peut choisir OpenAI, Anthropic, Google Gemini, Vertex AI, Novita ou des endpoints compatibles, et payer directement au fournisseur du modèle les frais de traitement.

Fonction principale

Vérification automatique des RP

Kody peut s’exécuter automatiquement après la création ou le dépôt d’une nouvelle PR, ou être déclenché manuellement via des commandes de commentaire. Il analyse les configurations applicables, collecte les différences et le contexte nécessaire, puis génère des suggestions directement dans le texte ainsi qu’un résumé optionnel pour la PR.

Identification des défauts et des problèmes de sécurité

L’examen portera sur les erreurs logiques, la validation des entrées, le contrôle des droits d’accès, la gestion des exceptions, les risques de sécurité, les performances et la maintenabilité. Il est recommandé de filtrer en fonction du degré de gravité et de la pertinence, ainsi que de supprimer les doublons, afin de réduire les commentaires redondants ou de faible valeur.

Vérification trans-fichier et de logique métier

Kody peut analyser les modifications en tenant compte du contexte du entrepôt et des informations transversales aux fichiers, et non seulement expliquer des segments de différences isolés. La vérification de la logique métier peut également comparer la mise en œuvre aux descriptions des tâches ou aux spécifications, mais cette capacité dépend d’une configuration correcte et d’un contexte accessible.

Kody Rules

L’équipe peut créer des règles de vérification en langage naturel et les appliquer par organisation, entrepôt, catalogue ou plage spécifique. Ces règles conviennent pour consolider les contraintes architecturales, les exigences de sécurité, les normes de test et les conventions d’entrepôt.

Mémoire d’équipe et apprentissage

Memories prend en compte la structure du répertoire de code, les conventions et les retours d’équipe comme contexte à haute priorité, afin d’influencer les revues ultérieures, l’analyse inter-fichiers et les discussions. Les mémoires peuvent être définies par dossier, dépôt ou organisation, et les mémoires générées par l’IA peuvent entrer dans le processus d’approbation.

Kody Issues

Lorsqu’une PR est fermée, les suggestions au niveau du fichier qui n’ont pas été mises en œuvre peuvent être automatiquement ajoutées à la liste des problèmes, en conservant l’emplacement du fichier, son niveau de gravité et le contexte de la suggestion initiale. Lorsque la PR correspondante est finalisée avec les modifications nécessaires, la plateforme peut les associer automatiquement et marquer le problème comme résolu.

Indicateurs d’ingénierie du cockpit

Cockpit permet d’observer l’efficacité des audits, la santé des règles, la qualité des entrepôts et les indicateurs de livraison, ce qui est utile pour que les responsables techniques comprennent l’état d’adoption. Ce module fait partie des avantages Teams et Enterprise ; il n’est pas inclus dans Community.

Plugins et MCP

Le plugin intègre des contextes métier externes tels que Jira dans le processus d’examen via MCP, et permet également de gérer des règles ou de créer des problèmes au sein des threads de commentaires. Actuellement marqué comme fonction de test, il ne doit pas être utilisé pour des opérations critiques en production sans avoir été vérifié.

CLI de terminal

Kodus CLI permet d’examiner directement l’espace de travail, les différences de staging, les branches ou les commits, et de générer des rapports structurés en fonction du niveau de gravité. Il prend en charge la prévisualisation et l’application de correctifs, l’installation de hooks avant le push, l’intégration dans des processus CI, ainsi que la fourniture d’une sortie compacte pour l’agent de codage.

Processus d’examen du code

1. Connectez-vous à la plateforme de stockage de code Git et sélectionnez l’organisation, le workspace et le répertoire pour lesquels vous souhaitez activer Kody.
2. Configurer la révision automatique ou manuelle, la branche cible, les chemins à ignorer, le niveau de gravité suggéré et les restrictions de fichiers.
3. Connectez votre clé de modèle, sélectionnez le modèle et définissez la limite mensuelle de dépenses pour le modèle.
4. Créer des Règles Kody et des mémoires adaptés aux équipes, aux entrepôts ou aux catalogues.
5. Lorsque le développeur crée une PR ou envoie un nouveau commit, Kody collecte les différences et le contexte associé.
6. Règles d’exécution de la plateforme, analyse inter-fichiers, filtrage des recommandations et suppression des doublons.
7. Kody propose des conseils spécifiques à côté des lignes de code et génère un résumé du PR en fonction de la configuration.
8. Le développeur juge si la suggestion est correcte, modifie le code ou continue la communication dans les commentaires.
9. Lorsqu’une analyse révisionnelle est nécessaire, déclenchez-la manuellement pour vérifier si la nouvelle soumission résout le problème.
10. Observer les performances, les recommandations restantes et les tendances de l’équipe via Cockpit et Kody Issues.

Déclenchement automatique, déclenchement manuel et saut

GitHub, GitLab et Forgejo permettent d’afficher des réactions natives pour les états en cours de traitement, terminé, sauté, sans licence ou erreur. Azure DevOps et Bitbucket ne disposent pas d’interfaces de réaction correspondantes, ce qui fait que certains états sont remplacés par des commentaires.

Kody Rules et la mémoire

Les règles et la mémoire peuvent réduire les interprétations répétées, mais les contraintes dues aux erreurs sont également amplifiées de manière continue. Il convient de désigner un responsable pour chaque règle et d’évaluer les faux positifs, les faux négatifs et la portée d’action par des tests réels sur des PR.

Kody Issues et suivi de la qualité

• Enregistrement des recommandations au niveau du fichier qui n’ont pas encore été mises en œuvre lorsque PR est fermé.
• Conserver l’entrepôt, l’emplacement du fichier, la catégorie et le contexte de la suggestion initiale.
• Gérer le niveau de gravité selon Critique, Élevé, Moyen et Faible.
• Utiliser Open, Resolu et Clôturé pour gérer les états de traitement.
• Filtrer par état, gravité, catégorie et entrepôt.
• Conserver les vues fréquemment utilisées pour que l’équipe puisse les consulter régulièrement.
• Tenter automatiquement de résoudre lors de la mise en œuvre des suggestions de modifications ultérieures du code.
• Les règles de niveau PR ne génèrent pas directement des problèmes traçables.

Plugins et contexte métier

Kodus MCP intègre des adaptateurs pour GitHub, GitLab, Bitbucket et Azure DevOps, ce qui évite l’installation de plugins distincts pour les opérations de base sur le code. Des plugins externes peuvent lire les tâches ou spécifications Jira, permettant ainsi que les recommandations soient plus en adéquation avec les conditions d’acceptation métier.

• Activer uniquement les outils réellement nécessaires à l’espace de travail actuel.
• Définir des identifiants aux droits minimaux pour les points d’extrémité externes.
• Vérifier que le lien de tâche donne à Kody des droits de lecture.
• La confirmation manuelle est maintenue pour les opérations d’écriture telles que la mise à jour de l’état des tâches.
• Vérifier les journaux, la conservation et les politiques de sécurité du serveur MCP personnalisé.
• Vérifier à nouveau le comportement après la mise à niveau de la fonction de test.
• Ne considérez pas par défaut le contenu des spécifications externes comme des instructions fiables.

Plateformes de code supportées

Modèles et BYOK

Tous les forfaits permettent par défaut aux utilisateurs de se connecter à leur propre compte de modèle, les frais de modèle étant facturés directement par le fournisseur correspondant ; Kodus ne rajoute aucun supplément sur les tokens. Il est possible de choisir un modèle commercial, un gateway d’entreprise cloud, un service d’agrégation ou des interfaces compatibles.

La tâche BYOK ne bascule pas discrètement vers le modèle hébergé par Kodus lorsque l’utilisateur n’a pas défini de modèle de secours. L’examen échoue en cas d’échec du modèle sélectionné ; l’équipe doit donc configurer ses propres stratégies de secours, de budget et d’alerte.

Édition gérée et auto-gérée

Architecture auto-hébergée

La version auto-hébergée se compose d’une application web, d’une API, d’un Worker de modération, d’un service Webhook, d’un gestionnaire MCP ainsi que de composants de file d’attente et de base de données. Docker Compose peut être utilisé, et des matériaux de déploiement pour Kubernetes et OpenShift sont également fournis.

• Définir une entrée stable pour le Webhook et la vérification de la signature.
• Autorisations réseau pour isoler les pages web, les API, les Workers et les services de données.
• Stocker les identifiants Git et les clés de modèle dans un système de gestion de clés.
• Créer des sauvegardes pour PostgreSQL, MongoDB et les files de messages.
• Restreindre la portée de l’accès du gestionnaire MCP aux systèmes externes.
• Déployer un proxy inversé, le chiffrement des transferts et le contrôle d’accès.
• File d’attente des tâches de surveillance, revue des échecs, tokens et croissance de l’espace de stockage.
• Vérifier la migration et le retrait de la base de données avant la mise à niveau.

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

1. Évaluer les différences entre Cloud et hébergement propre en termes de limites des données, de maintenance et de support.
2. Préparer un environnement répondant aux exigences de conteneurs, de bases de données, de files d’attente, de noms de domaine et de chiffrement des transferts.
3. Déployer les composants de l’application Kodus et définir une clé de production indépendante.
4. Configurer l’application de la plateforme Git, OAuth, Webhook ou des tokens d’accès.
5. Connecter les fournisseurs de modèles et limiter le budget de chaque environnement.
6. Créer des organisations, des espaces de travail, des entrepôts, des rôles et des règles de modération.
7. Utilisez le dépôt de test pour valider la déclenchement des PR, les commentaires, les tentatives de réessai et les retours d’état.
8. Tester la restauration des sauvegardes, les mises à niveau, le masquage des journaux et le renouvellement des identifiants.
9. Connectez-vous au entrepôt de production uniquement après avoir terminé les vérifications de sécurité et juridiques.
10. Mettre à jour continuellement les versions et surveiller les files d’attente, les retards, les faux positifs et les coûts des modèles.

Mode d'utilisation de la CLI

CLI convient pour vérifier les modifications locales avant la création d’un PR, et permet également d’accéder au cycle de correction automatique du CI ou de l’agent de codage. L’essai anonyme permet d’examiner 5 fois par jour, jusqu’à 10 fichiers par fois ; les restrictions après connexion dépendent du forfait, avec un maximum de 100 fichiers par fois.

1. Installez Kodus CLI et ouvrez un terminal dans le dépôt cible.
2. Effectuez d’abord une revue ordinaire sur l’espace de travail ou les différences temporaires.
3. Voir les problèmes regroupés par fichier et par gravité.
4. Vérifiez chaque suggestion avant d’accepter toutes les corrections automatiques.
5. Utilisez le mode de réparation pour appliquer les solutions aux problèmes rencontrés.
6. Pour coder des agents d’IA, on utilise un modèle de sortie de prompt structuré.
7. Dans CI, définir des conditions de blocage en fonction du niveau de gravité et du code de sortie.
8. Maintenir la cohérence entre les règles d’équipe et la configuration du site Web.

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.

Kodus classe les forfaits en fonction des fonctionnalités du produit et non du nombre de PR, offrant une révision illimitée de PR et un nombre illimité d’utilisateurs pour tous les forfaits utilisant des clés de modèle propres. Teams calcule le nombre de places en fonction des développeurs actifs ayant créé des PR au cours du mois, sans communiquer de nombre minimum de places.

Par défaut, pour Community, Teams et Enterprise, c’est l’utilisateur qui assume directement les frais de tokens du modèle ; le coût réel dépend de l’ampleur du PR, du contexte, du modèle et de la fréquence des revues. Enterprise peut également utiliser, selon un contrat, des clés gérées par Kodus.

Essai gratuit

Teams offre une période d’essai de 14 jours sans besoin de carte de crédit. L’essai comprend les fonctionnalités de groupe telles que Cockpit, des règles et des plugins illimités ainsi qu’une file d’attente prioritaire, et Kodus prend en charge les frais de modélisation pour les 5 premières revues de PR.

• La fonction Teams est restreinte pendant 14 jours, mais la modération de base ne sera pas interdite de manière permanente.
• Les 5 premières revues PR ne nécessitent pas de connexion préalable à la clé du modèle.
• Le accomplissement de certaines tâches d’accompagnement peut vous valoir des essais supplémentaires.
• Une fois le nombre de vérifications gratuites épuisé, vous pouvez continuer en connectant votre clé de modèle.
• Le modèle d’essai est sélectionné par Kodus ; une fois les clés personnelles connectées, vous pouvez choisir votre propre modèle.
• Le forfait annuel Teams est 20 % moins cher que l’offre publique mensuelle.
• L’annulation prend effet à la fin du cycle de facturation en cours.
• Les frais perçus ne sont pas remboursables en principe, sauf disposition contraire explicite.

Logiciels libres et licences

Le dépôt central de Kodus est public et maintenu en permanence, mais il fait l’objet d’une double licence. Le code, à l’exception des fichiers et des dossiers marqués comme étant de la version entreprise, est soumis à la licence AGPL-3.0, tandis que les parties marquées comme étant de la version entreprise sont régies par une licence commerciale ; il ne faut donc pas penser que toutes les fonctionnalités peuvent être utilisées sous AGPL.

Les plans d’entreprise, les licences commerciales et les dépôts open source peuvent coexister. Les organisations qui prévoient de distribuer des versions modifiées, de fournir des services en ligne ou d’intégrer dans des produits commerciaux doivent faire vérifier par leur service juridique les limites de l’AGPL et des licences commerciales.

Confidentialité et traitement des données

Le client conserve la propriété des données clients telles que le code, les métadonnées du dépôt, les PR, les commentaires et les configurations, et autorise Kodus à traiter ces éléments aux fins de fournir des services d’examen. La plateforme n’utilisera pas le code du client ni les données personnelles pour entraîner ou affiner les modèles de base, sauf si le client l’active explicitement.

Lors de l’examen, seules les différences et le contexte requis sont envoyés au fournisseur de modèles sélectionné ; Kodus conserve les recommandations, les métadonnées et autres résultats d’examen pour une présentation historique, afin de réduire les redondances et de calculer des indicateurs. Les utilisateurs BYOK sont également soumis aux conditions de traitement des données entre eux et le fournisseur de modèles.

Télémétrie auto-hébergée

Par défaut, les instances auto-hébergées envoient un battement cardiaque anonyme une fois par jour, contenant des comptes agrégés et des métadonnées de fonctionnement, sans inclure de code, d’identité ou d’informations permettant de tracer l’utilisateur. L’administrateur peut prévisualiser le contenu envoyé, ou désactiver la télémétrie via les paramètres de l’environnement.

• Vérifier les champs de télémétrie de la version actuelle avant le lancement.
• Enregistrer les décisions de mise en œuvre ou de désactivation dans un environnement réglementé.
• Restreindre les exportations de télémétrie vers des services spécifiques.
• Vérifiez à nouveau les changements des champs après la mise à niveau.
• Ne confondez pas les battements de cœur anonymes avec les journaux d’application ou le trafic des modèles.
• Désactiver la télémétrie ne remplace pas non plus l’examen du trafic de Git, des modèles et des plugins.

À qui s’adresse-t-il

• Équipes de développement qui souhaitent détecter automatiquement les défauts et les risques de sécurité dans les PR.
• Équipes de plateforme nécessitant une application uniforme des normes de codage et des contraintes architecturales.
• Les organisations qui utilisent GitHub, GitLab, Bitbucket ou Azure Repos.
• Équipes souhaitant choisir elles-mêmes le modèle et contrôler directement les frais de tokens.
• Les entreprises ayant besoin d’une plateforme d’audit de code open source auto-hébergée.
• Responsables de projet qui souhaitent suivre les recommandations non mises en œuvre et les tendances de qualité technique.
• Les développeurs qui doivent examiner le code localement, avant le déploiement ou dans le CI.
• Utilisateurs souhaitant faire participer Claude Code, Cursor, Codex ou Windsurf au cycle de révision des correctifs.
• Équipes de développement de produits qui doivent intégrer les spécifications Jira dans les revues de code.

Scénario typique

• Vérifier automatiquement les problèmes de sécurité, de performance et logiques après la création du PR.
• Restreindre les spécifications techniques des différents modules par des règles au niveau du catalogue.
• Vérifier avant la fusion que la mise en œuvre répond aux conditions d’acceptation de la tâche.
• Fournir un examen initial continu et cohérent pour les dépôts open source.
• Détecter des défauts évidents avant soumission locale et prévisualiser la correction.
• Dans le CI, définir un seuil d’échec pour les problèmes à haute gravité.
• Suivi des suggestions d’amélioration fermées dans les PR qui n’ont pas encore été mises en œuvre.
• Comparer la qualité et le coût des différents modèles dans un répertoire de code réel.
• Exécuter la pile d’applications et les points de terminaison des modèles sur des infrastructures propriétaires.

Avantages du produit

• Community est disponible gratuitement et prend en charge le Cloud ou l’hébergement propre.
• Le code source est publié, et la partie communautaire est sous AGPL-3.0.
• Pas de facturation en fonction du nombre de PR ; avec une clé personnalisée, tous les forfaits offrent une quantité illimitée de PR.
• Le modèle est neutre et prend en charge des endpoints compatibles.
• Aucun surcoût n’est appliqué pour les tokens de modèles fournis par l’utilisateur.
• Les règles, la mémoire et le contexte du entrepôt améliorent l’adaptabilité de l’équipe.
• Kody Issues ne met pas en œuvre les recommandations de suivi durable.
• CLI couvre les workflows locaux, CI et d’agent de codage.
• Prend en charge quatre plateformes Git commerciales majeures.
• Enterprise offre des fonctionnalités de gouvernance, des instances dédiées et des options de support.

Restrictions d'utilisation

• Les recommandations de l’IA sont probabilistes et peuvent être erronées, omettre des éléments ou ne pas être applicables.
• Aucun forfait ne vérifiera les PR contenant plus de 200 fichiers de modification.
• De grandes disparités réduisent la qualité du contexte et augmentent le coût du modèle.
• Les coûts BYOK varient en fonction du modèle, de l’ampleur du PR et du nombre de révisions.
• La conservation des données par les fournisseurs de modèles n’est pas déterminée séparément par Kodus.
• L’extension est actuellement en phase de test et n’est pas adaptée à l’exécution directe d’actions à haut risque.
• Des règles et des mémoires erronées génèrent continuellement des faux positifs systématiques.
• L’hébergement auto-géré nécessite la maintenance de la base de données, des files d’attente, des Webhooks, ainsi que des mises à jour et des sauvegardes.
• Les fichiers Enterprise ne sont pas couverts par la licence de la communauté AGPL.
• Teams ne propose que l’hébergement cloud ; les équipes auto-hébergées classiques doivent choisir l’option Community ou Enterprise.
• L’essai CLI anonyme est soumis à des limites de nombre d’utilisations par jour et de nombre de fichiers.

Liste de livraison et d’achat

1. Choisissez un dépôt pilote avec un code actif, des risques maîtrisés et des PR historiques.
2. Déterminer le mode de hébergement, les droits Git, le fournisseur de modèles et les exigences régionales des données.
3. Vérifier les fonctionnalités et les limites des licences pour Community, Teams et Enterprise.
4. Calculer le nombre de comptes de développeurs actifs et le budget mensuel en tokens pour les différents modèles.
5. Mettre en place des responsables de règles, des processus d’approbation mémorisée et d’accès aux plugins.
6. Tester la précision et la stabilité à l’aide de défauts connus, de code normal et de grands PR.
7. Statistiques sur le taux d’adoption des recommandations, le taux de faux positifs, les délais de révision et le temps de vérification manuelle.
8. Vérification du chiffrement des clés, des rôles, de l’audit, de la suppression, des sauvegardes et de la réponse aux événements.
9. Vérifier la télémétrie anonyme, les sorties réseau et le rollback des mises à jour en mode auto-hébergement.
10. Confirmer dans le contrat le remboursement, les SLA, le support, le DPA et la sortie de la migration.
11. Étendre progressivement le périmètre après avoir obtenu l’approbation en matière d’ingénierie, de sécurité, de confidentialité et de conformité juridique.

Questions fréquentes

Que fait Kodus principalement ?

Kodus, via Kody, effectue des revues de code d’IA sur les différences PR ou locales, afin d’aider les équipes à détecter des défauts, des problèmes de sécurité, de performance et de qualité, et d’adapter les processus d’équipe à l’aide de règles, de mémoires et d’indicateurs.

Kodus est-il gratuit ?

Community est gratuit à long terme, prend en charge le Cloud ou l’hébergement propre, et permet un nombre illimité de revues PR avec des clés de modèle personnalisées. Teams est facturé en fonction du nombre de développeurs actifs, tandis qu’Enterprise propose des tarifs sur mesure.

Comment Teams facture-t-il ?

Le paiement mensuel est de 10 dollars par développeur actif, ce qui équivaut à 8 dollars par an, avec un supplément pour les tokens de modèle. Seuls les développeurs qui créent des PR au cours du cycle de facturation sont comptabilisés comme actifs.

Est-ce qu’une carte de crédit est nécessaire pour l’essai ?

L’essai de 14 jours des fonctionnalités Teams ne nécessite pas de carte de crédit et comprend 5 revues PR gratuites avec des clés de modèle. Une fois ces sessions écoulées, vous pouvez utiliser vos propres clés de modèle pour continuer les revues.

Kodus utilise-t-il du code pour entraîner les modèles ?

Kodus n’utilisera pas de codes clients ou de données personnelles pour entraîner ou affiner le modèle de base, sauf si le client l’active explicitement. La manière dont le fournisseur de modèles choisi pour BYOK conserve et traite les demandes dépend du contrat entre l’utilisateur et ce fournisseur.

Kodus est-il entièrement open source ?

Le code communautaire est soumis à la licence AGPL-3.0, mais les fichiers et dossiers de la version entreprise sont régis par une licence commerciale. Il s’agit d’une structure à double licence, ce qui signifie que toutes les fonctionnalités Enterprise ne peuvent pas être considérées comme open source sous AGPL.

Peut-on le déployer sur son propre serveur ?

Oui, tant Community que Enterprise offrent des solutions self-hébergées. Teams est une solution cloud ; les utilisateurs qui choisissent l’hébergement propre doivent assumer eux-mêmes le déploiement, la base de données, les files d’attente, les Webhook, les mises à jour et les sauvegardes.

Quelles plateformes Git sont prises en charge ?

Il prend en charge principalement GitHub, GitLab, Bitbucket et Azure Repos ; la documentation de déploiement propose également une adaptation pour les événements Forgejo. La CLI permet d’examiner directement les différences Git locales et d’être utilisée dans le CI.

Résumé

Kodus convient aux équipes de développement qui souhaitent intégrer l’audit de code par IA dans leurs processus Git existants, tout en conservant le contrôle des modèles, des coûts et du déploiement. Community, gratuit, auto-hébergé, BYOK, Kody Rules, la mémoire d’équipe, Issues et la CLI forment un flux de travail complet pour la qualité du code.

Il ne peut pas remplacer l’évaluation manuelle, les tests, l’analyse statique et les audits de sécurité. Avant le déploiement, il convient de vérifier en détail les faux positifs et faux négatifs dans le stockage réel, les conditions relatives aux données du modèle, les limites entre AGPL et les licences d’entreprise, ainsi que les coûts de maintenance auto-hébergée.