Un problème d'infrastructure pour l'IA

La startup Falconer, qui développe des agents capables de répondre à des questions complexes d'ingénierie, s'est heurtée à un problème d'infrastructure majeur. Pour des requêtes comme « Qui a introduit ce bogue ? » ou « Qu'a changé la version 1.3 ? », ses agents avaient besoin d'un accès complet à l'historique Git, et non d'une simple vue filtrée via une API. Leur solution antérieure, basée sur des volumes EBS (Elastic Block Store) attachés à des conteneurs ECS, imposait un clone complet du dépôt à chaque tâche, une opération longue et redondante. Pour un petit dépôt, un clone pouvait prendre dix secondes ; pour un plus gros, plusieurs minutes. Leur objectif était de parvenir à un système de fichiers partagé et persistant, où le service d'ingestion écrirait une seule fois le clone, et où tous les autres services (interface utilisateur, agents) pourraient le lire sans avoir à le posséder.

Les limites des API GitHub

Une première piste, consistant à utiliser les API GitHub à la place d'un clone direct, a été écartée. Selon les développeurs de Falconer, l'API GitHub expose une surface git limitée : elle ne permet pas de git blame précis, de git log -S pour la recherche d'expressions, ni de git diff complet entre deux références arbitraires. De plus, les limites de débit (rate limits) sont rapidement atteintes lors de requêtes exploratoires multiples. L'agent se trouverait confronté à une « vue contrainte et médiatisée de l'historique », jugée insuffisante pour les besoins.

S3 Files : une alternative économique et performante

Falconer a alors évalué Amazon EFS (Elastic File System), avant de se tourner vers S3 Files, un nouveau service AWS lancé en avril 2026. Ce service présente une interface NFS v4.1 sur un bucket S3. Contrairement à une simple couche FUSE au-dessus des API objet S3, S3 Files est un véritable serveur NFS utilisant EFS comme cache haute performance, avec S3 comme stockage durable. Un benchmark mené sur un dépôt Next.js de 343 Mo et 28 000 fichiers a montré que les performances de S3 Files étaient très proches de celles d'EFS. Par exemple, un clone chronomètre 9 minutes 33 secondes avec S3 Files contre 9 minutes 59 secondes avec EFS. La recherche ripgrep de la fonction était de 1 minute 55 secondes (à froid) avec S3 Files contre 2 minutes 01 seconde avec EFS. Les performances à chaud sont également comparables (environ 37 secondes avec S3 Files contre 32 secondes avec EFS pour une même recherche).

Le principal avantage de S3 Files réside dans son coût : environ 0,023 dollar par Go-mois (tarifs standard S3), contre 0,30 dollar pour EFS, soit un rapport de 1 à 13. Pour des milliers de dépôts clients, cette différence est significative. De plus, S3 Files hérite de la durabilité multi-AZ de S3 et ne nécessite aucun plan de capacité.

Mise en œuvre et friction avec l'écosystème

Falconer a configuré le système avec Pulumi sur AWS. Le service d'interface utilisateur monte le système S3 Files en lecture-écriture sous /repos, avec un espace de nommage par organisation, fournisseur et dépôt (/repos/{orgId}/github/{owner}/{repo}). L'équipe a rencontré un point de friction : l'écosystème d'outils n'était pas encore totalement adapté. Le fournisseur standard @pulumi/aws ne supporte pas encore la configuration s3FilesVolumeConfiguration sur les définitions de tâches ECS, tout comme CloudFormation. Pour une couverture complète en infrastructure en tant que code (IaC), Falconer a migré sa définition de tâche vers @pulumi/aws-native. Le reste de l'infrastructure reste sur le fournisseur standard.

Fonctionnement du système

Le système repose sur deux mécanismes de synchronisation de dépôt. La voie « webhook » assure la fraîcheur en temps réel : lorsqu'une application GitHub cliente reçoit un événement push sur la branche par défaut, ou un événement installation_repositories ajoutant un nouveau dépôt, le service d'ingestion lance une tâche github-persistent-repo-sync. Cette tâche exécute un git fetch pour mettre à jour le clone existant. Le premier agent qui interroge un dépôt fraîchement cloné trouvera un système de fichiers « froid », mais les requêtes suivantes seront rapides grâce au pré-remplissage effectué par le service d'ingestion.

Une solution complète livrée en six semaines

L'ensemble de la solution a été développé et mis en production en environ six semaines. Falconer, une startup de moins de dix personnes, a ainsi résolu un problème complexe de partage de données et d'historique de code pour ses agents, en utilisant un service AWS récent. Le résultat est un système où le service d'ingestion clone le dépôt une fois, le « réchauffe », et où tous les agents et workflows peuvent y accéder de manière persistante et partagée.