Contexte et exigences

Les développeurs d’assistants conversationnels utilisent des fichiers de compétences (souvent au format JSON ou YAML) pour décrire des actions, des intents et des réponses. La question posée sur Hacker News souligne trois exigences : trouver les compétences, les organiser et vérifier leur bon fonctionnement. Sans un cadre de gestion, les équipes accumulent des définitions redondantes, des incohérences de schéma et des régressions fonctionnelles.

Ces exigences se traduisent en exigences techniques : traçabilité des modifications, validation de la syntaxe, exécution de tests automatisés et processus de mise à jour continue.

Architecture de stockage et versionnage

Le stockage le plus répandu repose sur un dépôt Git. Chaque compétence est un fichier isolé, nommé selon son domaine fonctionnel (ex. calendar/create_event.json). Git fournit un historique immuable ; chaque commit indique qui a ajouté ou modifié la compétence, à quelle version du modèle elle est destinée et pourquoi. En pratique, les équipes appliquent des conventions de nommage et des répertoires hiérarchiques pour éviter les collisions de noms.

{
  "name": "CreateEvent",
  "description": "Create a calendar event",
  "parameters": {
    "type": "object",
    "properties": {
      "title": {"type": "string"},
      "date": {"type": "string", "format": "date-time"}
    },
    "required": ["title", "date"]
  }
}

Le fragment ci‑dessus montre une compétence typique : un objet JSON contenant un nom, une description et un schéma de paramètres. Le format suit la spécification OpenAPI / JSON Schema, ce qui permet d’automatiser la validation.

Validation et tests automatisés

Avant d’intégrer une compétence, deux contrôles sont exécutés : validation du schéma et test d’exécution. La validation s’appuie sur ajv (Another JSON Schema Validator) ou jsonschema en Python, qui rejettent les fichiers non conformes. Un pipeline CI (GitHub Actions, GitLab CI) lance ces validateurs à chaque push.

Le test d’exécution invoque l’API du modèle avec des entrées factices. Le résultat attendu (type de réponse, présence de champs obligatoires) est comparé à un snapshot stocké dans le dépôt. En cas de divergence, le pipeline signale une régression, empêchant la promotion de la compétence vers l’environnement de production.

Évolution continue et gestion des dépendances

Les compétences évoluent avec les capacités du modèle. Un système de versionnage sémantique (v1.2.0) indique la compatibilité : une augmentation du chiffre majeur signale une rupture d’API, tandis que le chiffre mineur autorise l’ajout de nouveaux paramètres. Les fichiers requirements.txt ou environment.yml listent les bibliothèques de validation, garantissant que chaque build utilise les mêmes versions.

Pour les mises à jour incrémentales, les équipes utilisent des branches de fonctionnalité. Une fois les tests validés, la branche est fusionnée dans main et déclenche un déploiement automatisé vers le serveur de compétences. Ce processus assure que chaque modification est testée, versionnée et déployée sans intervention manuelle.