Aller au contenu
Alex ALAVO

Étude de cas d'ingénierie · Done 1:1 Digital

Concevoir un workflow assisté par IA pour des entretiens individuels structurés

Done 1:1 Digital transforme un processus managérial récurrent en un workflow produit traçable. La plateforme récupère le contexte OKR, guide la préparation, prend en charge les commentaires et la saisie vocale, orchestre l'assistance IA et produit un compte-rendu de réunion validé.

Rôle
Ingénierie full-stack, conception de workflow produit, intégrations externes, orchestration IA, tests et déploiement.

Responsabilités du système

  • SaaS
  • Intégration IA
  • Intégration API

Technologies

  • Laravel
  • Vue
  • Inertia
  • Claude API
  • GraphQL
  • Queues
  • State Machine
  • Railway

Preuves vérifiées

7 résultats vérifiés documentés ci-dessous.

Aperçu

Les entretiens individuels récurrents manager-collaborateur avaient besoin d'un contexte OKR pertinent, d'une visibilité sur les engagements précédents et d'un historique fiable pour chaque binôme, restreint à l'organisation approuvée.

  • Préparer les réunions avec un contexte OKR pertinent.
  • Rendre visibles les engagements précédents.
  • Soutenir la participation du manager et du collaborateur.
  • Générer un résumé final utile.
  • Préserver un historique fiable pour chaque binôme manager-collaborateur.
  • Restreindre l'accès à l'organisation approuvée.

Le problème

Les entretiens individuels hebdomadaires reposent souvent sur des notes éparses, une préparation inégale et un suivi manuel. Le système devait préserver la conversation humaine tout en ajoutant structure, contexte et continuité.

Contraintes qui ont façonné le système

  • Authentification restreinte au domaine.
  • Données OKR externes issues de Perdoo GraphQL.
  • Plusieurs phases avec des permissions différentes.
  • La sortie de l'IA devait rester contextuelle et maîtrisée.
  • La validation des réunions exigeait l'intégrité des données.
  • Le travail de synchronisation long ne pouvait pas bloquer le cycle de requête.

Architecture du système

Une architecture SaaS centrée sur Laravel combine Inertia et Vue pour l'expérience produit interactive, des tâches en arrière-plan pour la synchronisation des OKR, un workflow explicite à six états pour la progression des réunions et trois phases de prompts IA maîtrisées pour la préparation, l'analyse et le rapport final.

Diagramme de l'architecture du système : Navigateur, Application Laravel, MySQL, Travailleurs de file d'attente, Planificateur, API GraphQL Perdoo, API Claude, Envoi d'emails, Environnement d'exécution Railway.

client

Navigateur

Décisions d'ingénierie clés

Machine à états explicite

Accepté

Les permissions et actions disponibles pour une réunion dépendent de la phase en cours.

Modéliser le cycle de vie avec six états explicites : brouillon, prêt pour commentaire, prêt pour la réunion, en cours, terminé et archivé.

Pourquoi

  • Empêcher les actions invalides.
  • Rendre les permissions de l'interface prévisibles.
  • Améliorer les tests.
  • Préserver la traçabilité.

Alternatives envisagées

  • Indicateurs booléens de statut faiblement couplés

Compromis

  • Davantage de logique de transition, mais bien moins d'ambiguïté que des indicateurs booléens faiblement couplés.

Phases IA séparées

Accepté

L'assistance IA devait soutenir trois étapes distinctes du workflow de réunion - préparation, analyse et rapport final - sans se résumer à un unique prompt générique et difficile à maîtriser.

Utiliser trois interactions IA spécifiques au contexte plutôt qu'un unique prompt générique.

Pourquoi

  • Les différentes étapes nécessitent des objectifs différents.
  • Des responsabilités de prompt plus restreintes améliorent la maîtrise.
  • Le contexte peut être injecté délibérément.
  • Les sorties sont plus faciles à valider.

Alternatives envisagées

  • Un unique prompt générique gérant toutes les étapes de la réunion

Contenu de réunion signé

Accepté

La validation des réunions exigeait l'intégrité des données.

Créer une signature horodatée basée sur le contenu structuré final.

Pourquoi

  • Détecter les modifications non intentionnelles après validation.
  • Renforcer la confiance dans les comptes-rendus archivés.

Points clés de l'implémentation

  • OAuth Google et restriction au domaine de l'organisation.
  • Synchronisation des OKR Perdoo via des tâches en file d'attente.
  • Saisie vocale via la Web Speech API.
  • Contenu structuré stocké en JSON.
  • Contraintes de dates absolues dans le contenu généré par l'IA.
  • Déploiement sur Railway.

Qualité et exploitation

Tests

  • 37 tests automatisés.
  • Couverture des transitions d'état.
  • Débogage d'intégration sur schéma et données réels.
  • Séparation claire entre requêtes web et traitement en arrière-plan.

Résultats et preuves

  • Fait d'implémentation

    Workflow de réunion à six états

    Brouillon, prêt pour commentaire, prêt pour la réunion, en cours, terminé, archivé.

  • Fait d'implémentation

    Trois phases de prompts IA orchestrées

    Préparation, analyse et rapport final.

  • Fait d'implémentation

    Signature de contenu horodatée

    Détecte les modifications non intentionnelles après validation.

  • Métrique vérifiée

    Tests automatisés37

  • Fait d'implémentation

    Intégration GraphQL Perdoo

    Récupère le contexte OKR pour la préparation des réunions.

  • Fait d'implémentation

    Synchronisation OKR en file d'attente

    Les tâches en arrière-plan maintiennent le travail de synchronisation long hors du cycle de requête.

  • Capacité observable

    Déploiement en production disponible

    Déployé sur Railway.

Leçons tirées du système

  • L'IA doit soutenir un workflow, pas remplacer son modèle métier.
  • Des états explicites améliorent à la fois l'UX et la justesse du backend.
  • La synchronisation de données externes doit se situer hors du cycle de vie de la requête.