> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Self hosted scm artifacts

***

title: "SCM et artefacts auto-hébergés"
description: "Connecter Devin à vos dépôts de gestion de code source et à vos dépôts d’artefacts auto-hébergés"
icon: "server"
public: true
\---"

<div id="why-connect-devin-to-self-hosted-systems">
  ## Pourquoi connecter Devin à des systèmes auto-hébergés ?
</div>

Si votre organisation utilise des systèmes de gestion de code source auto-hébergés (comme GitLab) ou des dépôts d’artifacts (comme Artifactory), vous pouvez toujours tirer pleinement parti de Devin. En exposant de manière sécurisée ces services à l’infrastructure de Devin, votre équipe conserve le contrôle de ses systèmes tout en permettant à Devin de collaborer efficacement avec votre flux de travail de développement.

<div id="overview">
  ## Vue d'ensemble
</div>

Votre équipe peut créer un Network Load Balancer (NLB), autoriser les adresses IP statiques de Devin et publier un enregistrement DNS pour ce dernier. Cette approche :

* **Limite l'accès à une surface d'exposition réduite et maîtrisée** - Seules les adresses IP connues de Devin peuvent se connecter
* **Ne nécessite que quelques heures tout au plus** d'effort d'ingénierie pour la mise en place
* **Préserve votre infrastructure existante** - Pas besoin de migrer vers des solutions hébergées dans le cloud
* **Fournit une gestion centralisée** - Un équilibreur de charge unique et facultatif pour plusieurs services

<div id="prerequisites">
  ## Prérequis
</div>

Avant de configurer l’intégration, assurez-vous de disposer des éléments suivants :

* **GitLab auto-hébergé** (ou un autre système de gestion de code source) accessible depuis votre réseau
* **Référentiel d’artefacts auto-hébergé** (facultatif), comme Artifactory ou Nexus
* **Accès à l’administration réseau** pour configurer les pare-feu, les équilibreurs de charge et le DNS
* **Adresses IP statiques de Devin** – disponibles [ici](/fr/admin/common-issues#ip-whitelisting)

<Note>
  Cette intégration est disponible pour les clients disposant de l’offre Enterprise. Contactez [enterprise@cognition.ai](mailto:enterprise@cognition.ai) si vous avez besoin d’assistance.
</Note>

<div id="setup-options">
  ## Options de configuration
</div>

Vous disposez de deux approches principales pour exposer vos services auto-hébergés à Devin :

<div id="option-1-direct-ip-whitelisting-recommended">
  ### Option 1 : mise en liste d’autorisation directe d’adresses IP (recommandé)
</div>

Conservez votre infrastructure auto-hébergée existante et ajoutez simplement les adresses IP statiques de Devin à la liste d’autorisation au niveau du pare-feu.

**Pour la gestion du code source :**

1. Configurez votre pare-feu pour autoriser les connexions entrantes depuis les adresses IP de Devin (listées [ici](/fr/admin/common-issues#ip-whitelisting))
2. Assurez-vous que votre instance GitLab (ou autre SCM) est accessible via HTTPS
3. Fournissez l’URL à Devin lors de la configuration de l’intégration

**Pour les dépôts d’artefacts :**

1. Ajoutez les adresses IP de Devin à la liste d’autorisation de votre Artifactory/Nexus
2. Assurez-vous que le dépôt d’artefacts est accessible via HTTPS
3. Configurez les identifiants appropriés pour que Devin puisse accéder aux artefacts

<Note>
  Si vous utilisez un équilibreur de charge (load balancer) avec votre dépôt d’artefacts, consultez la section [Considérations relatives à l’équilibreur de charge](#load-balancer-considerations) ci-dessous pour des informations importantes sur la mise en liste d’autorisation des adresses IP.
</Note>

<div id="option-2-centralized-load-balancer">
  ### Option 2 : Load Balancer centralisé
</div>

Placez plusieurs services derrière un seul Application Load Balancer (ALB) ou Network Load Balancer (NLB) pour un filtrage d’IP centralisé.

**Avantages :**

* Point de gestion unique pour l’ensemble du filtrage réseau
* Prise en charge de plusieurs services internes avec des domaines différents
* Audit de sécurité et mise en conformité simplifiés

<div id="load-balancer-considerations">
  ## Considérations liées au load balancer
</div>

Lors du choix entre Application Load Balancer (ALB) et Network Load Balancer (NLB), tenez compte de la façon dont chacun gère l’autorisation par adresses IP :

**Application Load Balancer (ALB) - Recommandé pour la plupart des cas d’usage :**

* L’ALB fonctionne à la couche 7 (HTTP/HTTPS) et fournit des capacités de routage avancées
* Le trafic passe par un NAT, de sorte que vos services backend voient les adresses IP internes de l’ALB, et non les IP source de Devin
* **Pour les dépôts d’artefacts derrière un ALB :** vous devez configurer l’autorisation par adresses IP directement sur Artifactory/Nexus, car l’IP interne du load balancer sera celle vue par le dépôt
* Utilisez AWS WAF pour le filtrage IP au niveau de l’ALB (voir exemple ci-dessous)

**Network Load Balancer (NLB) - Adapté aux scénarios d’autorisation par IP :**

* Le NLB fonctionne à la couche 4 (TCP) et préserve les adresses IP source originales
* Vos services backend voient les IP source réelles de Devin
* **Pour les dépôts d’artefacts derrière un NLB :** l’autorisation par adresses IP au niveau du load balancer est suffisante, puisque les IP source sont conservées
* Nécessite une configuration manuelle des groupes de sécurité pour chaque adresse IP

<Tip>
  Bien que l’ALB soit généralement préféré pour sa flexibilité et sa facilité de gestion, le NLB fonctionne bien lorsque vous avez besoin d’autorisation par adresses IP au niveau du load balancer, sans configuration supplémentaire sur les services backend.
</Tip>

<div id="aws-implementation-example">
  ## Exemple d’implémentation AWS
</div>

Voici des exemples de configurations AWS pour les deux approches d’équilibreur de charge :

<div id="application-load-balancer-with-waf-easier">
  ### Application Load Balancer avec WAF (plus simple)
</div>

```bash theme={null}
# Créer un ensemble d'adresses IP avec les IP statiques de Devin
aws wafv2 create-ip-set \
  --name devin-allowed-ips \
  --scope REGIONAL \
  --ip-address-version IPV4 \
  --addresses 1.2.3.4/32 5.6.7.8/32 9.10.11.12/32 13.14.15.16/32

# Create a WAF web ACL
aws wafv2 create-web-acl \
  --name devin-access-control \
  --scope REGIONAL \
  --default-action Block={} \
  --rules file://waf-rules.json

# Associate the WAF with your ALB
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:region:account:regional/webacl/... \
  --resource-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/...
```

<Note>
  Remplacez les adresses IP par les adresses IP réelles figurant dans notre [documentation sur la liste d'autorisation d'adresses IP](/fr/admin/common-issues#ip-whitelisting).
</Note>

<div id="network-load-balancer-manual-security-groups">
  ### Network Load Balancer (Security Groups manuels)
</div>

```bash theme={null}
# Ajoutez des règles d'entrée pour chaque IP Devin à votre groupe de sécurité
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Répétez l'opération pour chaque adresse IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Poursuivez pour toutes les adresses IP Devin...
```

<div id="dns-configuration">
  ### Configuration DNS
</div>

Après avoir configuré votre équilibreur de charge, créez un enregistrement DNS que Devin pourra utiliser :

```bash theme={null}
# Exemple : Pointer gitlab.votreentreprise.com vers votre équilibreur de charge
# Le domaine sera résolu vers l'IP de l'équilibreur de charge, qui filtre le trafic
# pour autoriser uniquement les connexions depuis les IP en liste blanche de Devin

# Avec AWS Route 53 :
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://dns-change.json
```

Exemple `dns-change.json` :

```json theme={null}
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "gitlab.yourcompany.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z215JYRZR1TBD5",
        "DNSName": "your-alb-name-123456.us-west-2.elb.amazonaws.com",
        "EvaluateTargetHealth": false
      }
    }
  }]
}
```

<div id="integration-steps">
  ## Étapes d’intégration
</div>

Une fois votre infrastructure réseau configurée :

1. **Tester la connectivité** - Vérifiez que vos services sont accessibles depuis l’extérieur de votre réseau en utilisant le nom de domaine configuré
2. **Contacter le support Devin** - Contactez Cognition avec :

* L’URL de votre instance GitLab auto‑hébergée (par exemple, `https://gitlab.votreentreprise.com`)
* L’URL de votre dépôt d’artefacts (le cas échéant)
* Toute exigence particulière en matière d’authentification

3. **Finaliser la configuration de l’intégration** - Collaborez avec l’équipe Devin pour finaliser la connexion
4. **Configurer les dépôts** - Ajoutez vos dépôts à [Devin's Machine](https://app.devin.ai/machine)

<Tip>
  Testez votre configuration de filtrage d’adresses IP avant d’accorder l’accès à Devin en tentant de vous connecter depuis une adresse IP qui ne figure pas dans la liste d’autorisation. La connexion doit être bloquée.
</Tip>

<div id="best-practices">
  ## Bonnes pratiques
</div>

* **Utiliser HTTPS** - Exposez toujours les services en HTTPS avec des certificats SSL valides
* **Créer un compte de service dédié** - Configurez un compte spécifique pour Devin dans votre système GitLab/SCM
* **Surveiller les journaux d'accès** - Examinez régulièrement les journaux de connexion provenant des adresses IP de Devin
* **Documenter votre configuration** - Conservez une documentation interne de la configuration de votre équilibreur de charge et de votre DNS
* **Tester le basculement** - Assurez-vous que votre configuration peut gérer correctement les pannes de l'équilibreur de charge ou des services
* **Audits de sécurité réguliers** - Passez périodiquement en revue les services exposés et vérifiez les listes d'adresses IP autorisées

<div id="troubleshooting">
  ## Dépannage
</div>

**Devin ne peut pas se connecter à mon système auto-hébergé :**

* Vérifiez que toutes les [adresses IP de Devin](/fr/admin/common-issues#ip-whitelisting) figurent dans la liste d'autorisation
* Vérifiez que votre certificat SSL est valide et de confiance
* Assurez-vous que les enregistrements DNS sont correctement configurés et propagés
* Vérifiez que les règles de votre pare-feu autorisent le trafic HTTPS (port 443)

**Échecs d’authentification :**

* Confirmez que les identifiants du compte de service sont corrects
* Vérifiez que le compte de service dispose des autorisations appropriées dans votre système de SCM/de gestion d’artefacts
* Recherchez d’éventuelles restrictions d’authentification par adresse IP autres que celles définies dans la liste d’autorisation

**Problèmes de performance :**

* Surveillez les métriques de votre équilibreur de charge afin d’identifier les goulets d’étranglement
* Assurez-vous que vos services auto-hébergés disposent de ressources suffisantes
* Prenez en compte la proximité géographique entre votre infrastructure et les systèmes de Devin

<div id="support">
  ## Support
</div>

Pour obtenir de l'aide concernant les intégrations en auto-hébergement :

1. Créez un canal Slack Connect partagé avec notre équipe via [app.devin.ai/settings/support](https://app.devin.ai/settings/support)
2. Envoyez un e-mail à [enterprise@cognition.ai](mailto:enterprise@cognition.ai) avec les détails précis de votre configuration
3. Partagez les fichiers de configuration pertinents (avec les données sensibles masquées) lorsque vous signalez un problème