Produit et opérations
Préparer la prochaine rentrée ensemble, proposition par proposition.
Au départ…
Les campus proposent les formations de l’année suivante. Direction, opérations, pédagogie et communication doivent contribuer et savoir à qui revient la prochaine étape.
Ce que nous avons construit
Un parcours guidé en cinq étapes. La proposition reste sur le même enregistrement pendant que chaque équipe la complète, la valide et la transmet jusqu’à sa publication.
Entrez dans l’outil
Écran 1 sur 6Vue du catalogue
Rechercher les formations par campus, avec un diagnostic des champs visible.
Ce que nous voulons changer
Garder le fil de chaque proposition, de la demande du campus à la publication, et repérer les dossiers incomplets.
Comment c’est construitModèle de données, code, contrôles et autonomie des équipes
Parcours utilisateur
- 01
Le campus propose une offre existante ou nouvelle.
- 02
Chaque équipe responsable examine la même demande dans le circuit.
- 03
La communication publie l’offre validée ; le record conserve les échanges.
Structure de la base
| Entité / table | Champs clés | Relations |
|---|---|---|
| Rentrées | Étape courante · échéances · rentrée source | Une rentrée → plusieurs propositions |
| Promotions | Formation · site · statut de validation · publiable · journal | Une demande est un record Promotions dès sa création |
| Formations et filières | Statut · filière · formats | Une formation proposée rejoint le référentiel commun |
| Sites | Validateurs du catalogue | Les responsabilités campus sont configurées dans la donnée |
Implémentation technique
- Un seul statut indique l’étape courante. Les commentaires s’accumulent dans un journal daté.
- L’assistant repère les doublons et les options manquantes avant création. Il ne copie ni identifiants CRM source ni anciens compteurs.
- Le mode « Voir en tant que » est en lecture seule, avec garde dans les contrôles et dans les fonctions d’écriture.
Décision d’ingénierie
Rendre les échecs partiels visibles à l’écriture
Adapté des mises à jour du catalogue : lots séquentiels, résultat par enregistrement et progression. La simulation support reste en lecture seule ; cet extrait la revérifie avant chaque lot. Un échec n’annule pas les lots précédents. Les identifiants en échec doivent être revus avant reprise ; ce contrôle local ne remplace pas les droits Airtable.
export async function updateCatalogue(table, updates, context, onProgress) { const savedIds = []; const failed = []; let processed = 0; for (let offset = 0; offset < updates.length; offset += 50) { // Recheck after awaits: the user may have entered support preview. if (context.isImpersonating()) { return { status: "stopped-read-only", savedIds, failed, processed }; } const permission = table.checkPermissionsForUpdateRecords(); if (!permission.hasPermission) { return { status: "stopped-permission", savedIds, failed, processed }; } const batch = updates.slice(offset, offset + 50); try { await table.updateRecordsAsync(batch); savedIds.push(...batch.map(row => row.id)); } catch (error) { // Keep the affected record IDs; never report the whole run as saved. for (const row of batch) { failed.push({ id: row.id, reason: "write-failed" }); } } processed += batch.length; onProgress?.({ processed, total: updates.length }); } return { status: failed.length ? "partial" : "saved", savedIds, failed, processed };}Extrait adapté de l’implémentation
Contrôles et limites
- Les rôles du circuit sont des règles d’usage ; les accès Airtable sous-jacents doivent être configurés.
- Le journal des commentaires est un historique applicatif, pas un journal d’audit inaltérable.
Qui peut contribuer
- Campus : déposer et compléter les demandes dans le parcours guidé.
- Builders : entretenir formations, filières, validateurs et échéances.
- Développeurs : étendre le circuit en préservant statuts et gardes d’écriture.
Ce qui documente ce cas
Le catalogue, le guide contextuel et le code reposent sur le même circuit de validation. Le diagnostic des champs rend la configuration manquante visible aux builders.