Vue d’ensemble
- Seule l’autorisation
User.Readest demandée lors de l’approbation Entra — elle sert uniquement à établir l’identité - L’approbation Entra à elle seule n’accorde pas l’accès aux dépôts ni au code
- L’accès aux dépôts est entièrement contrôlé par les autorisations que vous attribuez dans Azure DevOps
Prérequis
- un compte Devin Enterprise disposant de l’autorisation de gérer les intégrations
- un administrateur Microsoft Entra pouvant accorder le consentement administrateur pour les applications
- un administrateur de l’organisation Azure DevOps pouvant ajouter des utilisateurs et attribuer des autorisations
Configuration de l’intégration
- Connectez-vous à votre compte Devin sur app.devin.ai.
- Dans un autre navigateur ou une fenêtre de navigation privée, connectez-vous à Azure DevOps (requis pour l’étape 6).
- Dans votre compte Devin Enterprise, accédez à Settings > Enterprise Settings > Integrations et sélectionnez Azure DevOps.
- Ouvrez le menu déroulant du bouton Connect et sélectionnez Connect with service principal.
-
Vous êtes redirigé vers Microsoft pour autoriser Devin à accéder à votre tenant. Une fois l’autorisation approuvée, vous revenez sur la page d’intégration Azure DevOps dans Devin, qui affiche désormais une section Add organization with service principal.
- L’approbation crée un principal de service dans votre tenant Microsoft Entra
- Cette étape demande uniquement
User.Read— elle n’accorde pas l’accès aux dépôts
-
Dans Azure DevOps, accédez à Organization Settings > Users :
- Cliquez sur Add Users et ajoutez le principal de service (
Cognition Azure DevOps Service Principal) - Sélectionnez Basic comme niveau d’accès (Stakeholder ne suffit pas — les API exigent Basic)
- Ajoutez-le à tous les projets auxquels vous souhaitez que Devin ait accès
- Assignez le principal de service aux Groups Azure DevOps pertinents (généralement Project Contributors)
- Cliquez sur Add Users et ajoutez le principal de service (
- De retour dans Devin, dans la section Add organization with service principal de la page d’intégration Azure DevOps, saisissez le nom de l’organisation Azure DevOps de l’étape précédente, puis cliquez sur Add.
- Dans Devin, sélectionnez Git Permissions dans votre intégration Azure DevOps, choisissez une sous-organisation et accordez des autorisations au niveau du Group ou du Repository.
- Pour chaque Organization à laquelle des autorisations ont été accordées, accédez à Devin’s Settings > Devin’s Machine, cliquez sur + Repository et intégrez les dépôts.
Ce à quoi Devin a accès
| Capacité | Description |
|---|---|
| Lister les dépôts | Consulter les dépôts disponibles et leurs métadonnées |
| Consulter les branches | Accéder aux informations sur les branches et à l’historique des commits |
| Créer des pull requests | Ouvrir de nouvelles PR pour des modifications de code |
| Consulter les pull requests | Accéder aux événements, commentaires et au statut des PR |
| Pousser du code | Pousser de nouvelles branches et de nouveaux commits vers les dépôts |
Si votre organisation a besoin que Devin prenne en charge d’autres domaines Azure DevOps à l’avenir, veuillez contacter enterprise@cognition.ai pour discuter de vos besoins.
Considérations de sécurité
- Autorisations Entra minimales — Seule l’autorisation
User.Readest demandée. Aucun accès en lecture à l’ensemble de l’annuaire, aucune visibilité sur l’appartenance aux groupes et aucun contrôle administratif. - Autorisation explicite — L’approbation Entra seule n’accorde aucun accès à Azure DevOps. Tout accès aux dépôts doit être explicitement attribué par votre administrateur Azure DevOps.
- Identifiants chiffrés — Tous les tokens sont chiffrés et stockés en toute sécurité.
- Accès limité — Les autorisations peuvent être limitées à des projets, des dépôts et des opérations spécifiques via l’interface Enterprise de Devin.
- Traçabilité — L’activité est consignée dans les journaux de connexion Entra et les journaux d’audit d’Azure DevOps.
- Politiques de branche respectées — Les PR de Devin sont soumises aux mêmes politiques de branche et aux mêmes exigences de revue que n’importe quel autre contributeur.
Bonnes pratiques
- Utilisez des autorisations au niveau du dépôt — Accordez à Devin l’accès uniquement aux dépôts et projets spécifiques dont il a besoin, plutôt qu’un accès à l’échelle de l’organisation.
- Activez les politiques de branche — Configurez des politiques de branche dans Azure DevOps pour garantir que toutes les modifications passent par des processus de révision appropriés avant d’être fusionnées.
- Surveillez les journaux d’audit — Consultez régulièrement les journaux d’audit Azure DevOps et les journaux de connexion Entra concernant l’activité du principal de service.
Dépannage
- Vérifiez que l’utilisateur qui approuve dispose de l’autorisation d’accorder le consentement administrateur pour les applications dans votre tenant Entra
- Si votre tenant restreint le consentement aux applications, un administrateur général ou un administrateur d’applications cloud devra peut-être accorder ce consentement
- Vérifiez que le consentement administrateur s’est bien déroulé dans votre portail Entra, sous Applications d’entreprise (recherchez
Cognition Azure DevOps Service Principal) - Assurez-vous que le principal de service a bien été ajouté explicitement à votre organisation Azure DevOps sous Organization Settings > Users
- Si le principal de service est soumis à des politiques d’accès conditionnel imposant la MFA, l’actualisation du token échouera sans message d’erreur. Créez une exclusion d’accès conditionnel pour le principal de service vis-à-vis de l’application Devin.
- Vérifiez que le principal de service a bien été ajouté à l’organisation Azure DevOps sous Organization Settings > Users
- Confirmez que le niveau d’accès est défini sur Basic (Stakeholder est insuffisant pour l’accès à l’API)
- Vérifiez que les autorisations du dépôt ont été accordées dans les Enterprise Settings de Devin
- Assurez-vous que les dépôts ont été ajoutés à Devin’s Machine
- Confirmez que le principal de service dispose des autorisations de contributeur sur le dépôt cible
- Vérifiez que les politiques de branche ne bloquent pas la création de la PR
- Vérifiez que la branche cible existe et est accessible