Première cohorte de pilotes terrain

La cohorte 0.3 est ouverte aux indépendants, petites et moyennes structures, associations et services publics de Suisse et de l’Union européenne. Elle sert à tester le playbook dans un travail réel. Ce n’est pas un appel à témoignages et elle ne suppose pas que l’IA améliorera le processus.

Deux couches dans une même 0.3

Chaque pilote part d’une fourchette extrapolée ou d’une hypothèse locale préenregistrée. Cette première couche sert à planifier et peut être construite à partir de tâches comparables dans d’autres organisations. La seconde couche est l’observation du pilote sur le dénominateur complet. Le rapport conserve la projection, le résultat et leur écart afin d’améliorer les futures transpositions. Seule la couche observée peut compter comme retour terrain admis, mais les deux appartiennent au travail 0.3.

Utilisez l’entrée publique du pilote pour proposer un pilote non identifiant. L’issue contient uniquement des métadonnées de coordination. Les preuves brutes restent dans un système privé autorisé.

Objectif de la cohorte

La version 0.3 exige au moins trois rapports admis :

1. un processus non agentique ou avec copilote, par exemple recherche, classification, prévision, conversation, traitement multimodal ou génération assistée ;
2. un agent métier A2 borné qui porte un processus complet pendant qu’une personne conserve l’approbation ou le blocage défini ;
3. un contexte additionnel qui garantit que les trois rapports couvrent ensemble la Suisse et l’Union européenne, tout en testant un autre travail, public, secteur ou ensemble de conditions d’exploitation.

Un candidat avec agence orchestrée est utile seulement lorsqu’un véritable système existe déjà et peut être comparé à une architecture plus simple. Il n’est pas exigé pour la 0.3. Sans un tel rapport, la performance terrain d’une agence reste non démontrée.

Trois rapports constituent un seuil d’apprentissage, pas une validation statistique. Ils ne créent pas une référence universelle de productivité.

Parcours de participation

1. Cadrer. Ouvrir une entrée publique avec alias, mode d’usage, territoire, processus borné, étape actuelle et question de décision.
2. Accepter le protocole. Nommer le responsable local des preuves, le réviseur indépendant, l’autorité de publication et la voie de retrait avant la mesure.
3. Figer la comparaison. Consigner version du système, charge complète, situation initiale, sources transférées, fourchette prévue, travail humain, exclusions, cas, seuils, incidents et conditions d’arrêt.
4. Exécuter en privé. Garder prompts, logs, captures, données personnelles, contenu client, secrets et détails de sécurité hors de GitHub.
5. Comparer et réviser. Positionner le résultat observé par rapport à la fourchette, expliquer l’écart, puis vérifier provenance, dénominateur, échecs, anonymisation, limites de transfert et cohérence avec les preuves brutes.
6. Admettre ou retenir. Publier uniquement un rapport nettoyé qui satisfait toutes les règles du registre. Retenir tout élément dangereux, invérifiable ou réidentifiant.

Observations minimales

Chaque pilote consigne la charge complète et la part réellement éligible à l’IA. Les mesures communes portent sur résultats acceptés, temps humain, corrections majeures, incidents critiques, complétude des traces et effort de mise en œuvre. Le profil d’évaluation change ensuite selon le mode d’usage :

État public

• Zone de recrutement : Suisse et Union européenne
• Objectif : 3 rapports admis
• Rapports admis : 0
• Registre public : field-notes/index.json

Une entrée, un pilote actif ou un brouillon ne modifie pas le nombre de rapports admis. Ce nombre change uniquement après revue indépendante et publication.