Contexte juridique et souveraineté des données

Le service affirme que tous les dépôts sont stockés sur des serveurs situés dans l'Union européenne. Cette localisation empêche toute requête fondée sur le Cloud Act américain, car les données ne sont jamais transférées vers des juridictions hors UE. En pratique, le cadre juridique applicable est le RGPD, ce qui impose des exigences de consentement, de traçabilité et de droit à l'oubli. Aucun mécanisme de « kill‑switch » américain n'est déclaré, ce qui réduit le risque d’interruption soudaine imposée par une autorité étrangère.

Le texte ne fournit pas de métriques précises (nombre de datacenters, capacité de stockage ou accords de redondance). L'absence de ces indicateurs empêche une évaluation quantitative de la conformité légale au-delà de la simple affirmation de résidence des serveurs.

Architecture, compatibilité et flux d’importation

Le service propose une interface de programmation compatible avec les endpoints de GitHub (/api/v1). Cette compatibilité signifie que les scripts écrits pour GitHub peuvent être réorientés vers la nouvelle base URL sans modification du code, à condition que les appels restent dans le sous‑ensemble supporté. Aucun benchmark de performance n’est fourni, ce qui laisse incertain l’impact de la traduction des appels sur la latence.

L’importation des dépôts s’effectue via un client CLI nommé pun. Le processus se déroule entièrement sur la machine de l’utilisateur, garantissant que le jeton d’accès GitHub reste local. Le code suivant illustre la commande de base :

pun import

Sans arguments, la commande liste les dépôts GitHub, puis l’utilisateur sélectionne ceux à migrer. L’importation conserve l’historique Git, les labels, les issues, ainsi que les pull‑requests fermées ou fusionnées, avec leurs horodatages et attributions d’auteur. Cette conservation des métadonnées repose sur l’accès à l’API GitHub, mais le service ne précise pas le traitement des éventuelles limites de taux (rate‑limits) ou des erreurs réseau, ce qui pourrait affecter la complétude des migrations à grande échelle.

Le service propose également une authentification à deux facteurs via TOTP ou passkey, renforçant la protection du compte contre les compromissions. Aucun chiffre n’est fourni sur le taux de réussite des logins sécurisés ou sur les éventuelles exigences de rotation des clés.

Disponibilité, gestion du « slop » et absence de formation IA

La promesse d’« always online » se traduit par un focus sur la disponibilité, mais le texte ne cite aucun accord de niveau de service (SLA), aucune métrique de temps moyen entre pannes (MTBF) ni de récupération (MTTR). Sans ces indicateurs, il reste impossible de comparer objectivement la résilience du service à celle d’opérateurs plus établis.

Le concept de « slop » désigne les contributions de faible valeur qui polluent les dépôts. Le service affirme bloquer ces contributions, mais ne décrit pas le mécanisme de détection (règles heuristiques, filtres de contenu, signatures). L’absence de transparence technique empêche d’évaluer le risque de faux positifs qui pourraient empêcher des contributions légitimes.

Enfin, le service garantit qu’aucun code hébergé n’est utilisé pour entraîner des modèles de machine learning, ni par le service ni par ses partenaires. Cette clause, bien que claire, n’est appuyée par aucun audit ou certificat tiers, ce qui laisse la vérifiabilité de la promesse à l’appréciation de l’utilisateur.

En résumé, le service propose une infrastructure de Git entièrement européenne, une compatibilité API avec GitHub, un outil d’importation local et des mesures de sécurité standard. Le manque de données chiffrées sur la capacité d’infrastructure, les SLA et les mécanismes de filtrage constitue la principale limitation de l’analyse technique disponible.