Choisir un modèle
- Prise de notes de réunion générale
- Procès-verbal de réunion standard
- Procès-verbal formel / de conseil d'administration
- Prise de notes de réunion individuelle (1:1)
- Point d'équipe / Réunion hebdomadaire
- Réunion quotidienne (Daily Standup)
- Appel commercial
- Réunion client
- Revue de projet / État d'avancement
- Lancement de projet
- Notes d'entretien
- Réunion de direction
- Journal des décisions
- Plan d'action
- Rétrospective
- Brainstorming / Atelier
1. Modèle de prise de notes de réunion générale
Modèle vierge
Réunion : [Nom de la réunion]
Date : [AAAA-MM-JJ]
Heure : [Début - Fin]
Lieu / Lien : [Salle ou lien de la réunion]
Animateur : [Nom]
Secrétaire : [Nom]
Participants : [Noms]
Objectif
[Ce que cette réunion doit accomplir]
Ordre du jour
1. [Sujet]
2. [Sujet]
3. [Sujet]
Notes de discussion
- [Sujet] : [Faits clés, contexte, préoccupations et points de vue]
- [Sujet] : [Faits clés, contexte, préoccupations et points de vue]
Points clés
- [Point clé]
- [Point clé]
Décisions
- [Décision] - Responsable de la décision : [Nom]
Plan d'action
- [Tâche] - Responsable : [Nom] - Échéance : [Date] - Statut : [Non commencé / En cours / Terminé]
Risques / Obstacles
- [Risque ou obstacle]
Questions en suspens
- [Question]
Parking
- [Sujet reporté à plus tard]
Prochaine réunion / Suivi
Date : [Date]
Objectif : [Ce qui doit être fait ensuite]
Date : [AAAA-MM-JJ]
Heure : [Début - Fin]
Lieu / Lien : [Salle ou lien de la réunion]
Animateur : [Nom]
Secrétaire : [Nom]
Participants : [Noms]
Objectif
[Ce que cette réunion doit accomplir]
Ordre du jour
1. [Sujet]
2. [Sujet]
3. [Sujet]
Notes de discussion
- [Sujet] : [Faits clés, contexte, préoccupations et points de vue]
- [Sujet] : [Faits clés, contexte, préoccupations et points de vue]
Points clés
- [Point clé]
- [Point clé]
Décisions
- [Décision] - Responsable de la décision : [Nom]
Plan d'action
- [Tâche] - Responsable : [Nom] - Échéance : [Date] - Statut : [Non commencé / En cours / Terminé]
Risques / Obstacles
- [Risque ou obstacle]
Questions en suspens
- [Question]
Parking
- [Sujet reporté à plus tard]
Prochaine réunion / Suivi
Date : [Date]
Objectif : [Ce qui doit être fait ensuite]
Exemple rempli
Réunion : Préparation du lancement produit Q4
Date : 2026-09-10
Heure : 10:00 - 10:45 (PT)
Lieu / Lien : Zoom
Animateur : Maya Chen
Secrétaire : Daniel Ruiz
Participants : Maya Chen, Daniel Ruiz, Priya Shah, Leo Martin, Erin Cole
Objectif
Confirmer si la date de lancement du 6 octobre est toujours réaliste et assigner les tâches pour les risques de lancement restants.
Ordre du jour
1. État de préparation du produit
2. Site web et supports e-mails
3. Couverture du support
4. Risques de lancement
Notes de discussion
- État de préparation du produit : L'AQ a résolu 38 des 41 problèmes bloquants. Deux problèmes restants affectent la migration des comptes ; un affecte le parcours d'intégration Android.
- Site web et supports e-mails : Les captures d'écran finales sont approuvées. La page de tarification nécessite encore une révision juridique avant publication.
- Couverture du support : La couverture du week-end n'est pas encore confirmée. Erin a proposé un roulement de deux personnes pour le week-end de lancement.
- Risques de lancement : Le bug d'intégration Android est le seul problème que le groupe considère comme susceptible de déplacer la date de lancement.
Points clés
- Le 6 octobre reste la date de lancement visée.
- Le problème d'intégration Android nécessite une mise à jour "go/no-go" d'ici le 18 septembre.
- La révision juridique est la dépendance critique pour la page de tarification.
Décisions
- Maintenir le 6 octobre comme date de lancement - Responsable de la décision : Maya Chen
- Utiliser un roulement de deux personnes pour le support du week-end de lancement - Responsable de la décision : Erin Cole
Plan d'action
- Résoudre le bug d'intégration Android - Responsable : Priya Shah - Échéance : 2026-09-18 - Statut : En cours
- Envoyer la page de tarification au service juridique - Responsable : Daniel Ruiz - Échéance : 2026-09-12 - Statut : Non commencé
- Publier le planning de support du week-end de lancement - Responsable : Erin Cole - Échéance : 2026-09-22 - Statut : Non commencé
Risques / Obstacles
- Le bug d'intégration Android pourrait affecter la préparation au lancement.
- La page de tarification ne peut être publiée sans l'approbation juridique.
Questions en suspens
- Le test de migration de compte nécessitera-t-il un second passage de régression complet ?
Parking
- Conception de l'enquête client post-lancement.
Prochaine réunion / Suivi
Date : 2026-09-18
Objectif : Revue go/no-go pour l'intégration Android et l'approbation de la page de tarification.
Date : 2026-09-10
Heure : 10:00 - 10:45 (PT)
Lieu / Lien : Zoom
Animateur : Maya Chen
Secrétaire : Daniel Ruiz
Participants : Maya Chen, Daniel Ruiz, Priya Shah, Leo Martin, Erin Cole
Objectif
Confirmer si la date de lancement du 6 octobre est toujours réaliste et assigner les tâches pour les risques de lancement restants.
Ordre du jour
1. État de préparation du produit
2. Site web et supports e-mails
3. Couverture du support
4. Risques de lancement
Notes de discussion
- État de préparation du produit : L'AQ a résolu 38 des 41 problèmes bloquants. Deux problèmes restants affectent la migration des comptes ; un affecte le parcours d'intégration Android.
- Site web et supports e-mails : Les captures d'écran finales sont approuvées. La page de tarification nécessite encore une révision juridique avant publication.
- Couverture du support : La couverture du week-end n'est pas encore confirmée. Erin a proposé un roulement de deux personnes pour le week-end de lancement.
- Risques de lancement : Le bug d'intégration Android est le seul problème que le groupe considère comme susceptible de déplacer la date de lancement.
Points clés
- Le 6 octobre reste la date de lancement visée.
- Le problème d'intégration Android nécessite une mise à jour "go/no-go" d'ici le 18 septembre.
- La révision juridique est la dépendance critique pour la page de tarification.
Décisions
- Maintenir le 6 octobre comme date de lancement - Responsable de la décision : Maya Chen
- Utiliser un roulement de deux personnes pour le support du week-end de lancement - Responsable de la décision : Erin Cole
Plan d'action
- Résoudre le bug d'intégration Android - Responsable : Priya Shah - Échéance : 2026-09-18 - Statut : En cours
- Envoyer la page de tarification au service juridique - Responsable : Daniel Ruiz - Échéance : 2026-09-12 - Statut : Non commencé
- Publier le planning de support du week-end de lancement - Responsable : Erin Cole - Échéance : 2026-09-22 - Statut : Non commencé
Risques / Obstacles
- Le bug d'intégration Android pourrait affecter la préparation au lancement.
- La page de tarification ne peut être publiée sans l'approbation juridique.
Questions en suspens
- Le test de migration de compte nécessitera-t-il un second passage de régression complet ?
Parking
- Conception de l'enquête client post-lancement.
Prochaine réunion / Suivi
Date : 2026-09-18
Objectif : Revue go/no-go pour l'intégration Android et l'approbation de la page de tarification.
Modèle prêt pour l'IA
TÂCHE
Convertir la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme une action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser "Non spécifié" pour un champ requis manquant.
- Utiliser "Non résolu" pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, actions et questions en suspens séparées.
- Préserver les incertitudes et désaccords lorsqu'ils existent.
FORMAT DE SORTIE
Réunion : [ ]
Date : [ ]
Heure : [ ]
Lieu / Lien : [ ]
Animateur : [ ]
Secrétaire : [ ]
Participants : [ ]
Objectif
[ ]
Ordre du jour
1. [ ]
Notes de discussion
- [Sujet] : [ ]
Points clés
- [ ]
Décisions
- [Décision] - Responsable de la décision : [ ]
Plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ] - Statut : [ ]
Risques / Obstacles
- [ ]
Questions en suspens
- [ ]
Parking
- [ ]
Prochaine réunion / Suivi
Date : [ ]
Objectif : [ ]
Ne renvoyer que le modèle complété.
Convertir la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme une action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser "Non spécifié" pour un champ requis manquant.
- Utiliser "Non résolu" pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, actions et questions en suspens séparées.
- Préserver les incertitudes et désaccords lorsqu'ils existent.
FORMAT DE SORTIE
Réunion : [ ]
Date : [ ]
Heure : [ ]
Lieu / Lien : [ ]
Animateur : [ ]
Secrétaire : [ ]
Participants : [ ]
Objectif
[ ]
Ordre du jour
1. [ ]
Notes de discussion
- [Sujet] : [ ]
Points clés
- [ ]
Décisions
- [Décision] - Responsable de la décision : [ ]
Plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ] - Statut : [ ]
Risques / Obstacles
- [ ]
Questions en suspens
- [ ]
Parking
- [ ]
Prochaine réunion / Suivi
Date : [ ]
Objectif : [ ]
Ne renvoyer que le modèle complété.
2. Modèle de procès-verbal de réunion standard
Modèle vierge
Nom de la réunion : [ ]
Date : [AAAA-MM-JJ]
Heure : [Début - Fin]
Lieu : [ ]
Président / Animateur : [ ]
Secrétaire : [ ]
Participants : [ ]
Absents : [ ]
Objectif de la réunion
[ ]
Point d'ordre du jour 1 : [Titre]
Résumé de la discussion :
[Résumé factuel concis]
Décision :
[Décision ou Aucune]
Action :
[Tâche - Responsable - Échéance]
Point d'ordre du jour 2 : [Titre]
Résumé de la discussion :
[ ]
Décision :
[ ]
Action :
[ ]
Autres sujets
[ ]
Résumé des décisions
- [Décision]
Résumé du plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine réunion
Date : [ ]
Clôture
Heure : [ ]
Procès-verbal rédigé par : [ ]
Date : [AAAA-MM-JJ]
Heure : [Début - Fin]
Lieu : [ ]
Président / Animateur : [ ]
Secrétaire : [ ]
Participants : [ ]
Absents : [ ]
Objectif de la réunion
[ ]
Point d'ordre du jour 1 : [Titre]
Résumé de la discussion :
[Résumé factuel concis]
Décision :
[Décision ou Aucune]
Action :
[Tâche - Responsable - Échéance]
Point d'ordre du jour 2 : [Titre]
Résumé de la discussion :
[ ]
Décision :
[ ]
Action :
[ ]
Autres sujets
[ ]
Résumé des décisions
- [Décision]
Résumé du plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine réunion
Date : [ ]
Clôture
Heure : [ ]
Procès-verbal rédigé par : [ ]
Exemple rempli
Nom de la réunion : Revue hebdomadaire des opérations
Date : 2026-09-08
Heure : 14:00 - 14:50 (ET)
Lieu : Salle de conférence B / Teams
Président / Animateur : Jordan Lee
Secrétaire : Sofia Patel
Participants : Jordan Lee, Sofia Patel, Marcus Green, Hana Kim, Alex Reed
Absents : Aucun
Objectif de la réunion
Passer en revue les performances de traitement, les postes vacants et l'inventaire de septembre.
Point d'ordre du jour 1 : Performances de traitement
Résumé de la discussion :
Le temps moyen de traitement des commandes est passé de 7,8 à 9,1 heures la semaine dernière. Marcus a attribué cette hausse à deux arrivages tardifs et à une panne temporaire d'un poste d'emballage.
Décision :
Conserver l'objectif de niveau de service actuel et revoir après deux cycles d'expédition normaux.
Action :
Marcus Green fournira une comparaison du temps de traitement sur deux semaines avant le 2026-09-22.
Point d'ordre du jour 2 : Effectifs du week-end
Résumé de la discussion :
Le quart du samedi manque de deux personnes pour les trois prochains week-ends. Hana a confirmé que quatre employés à temps partiel sont disponibles.
Décision :
Proposer les quarts du samedi aux employés à temps partiel formés avant de demander des heures supplémentaires.
Action :
Hana Kim finalisera le planning du week-end de septembre d'ici le 2026-09-11.
Point d'ordre du jour 3 : Inventaire
Résumé de la discussion :
L'inventaire complet est maintenu au 26 septembre. Le service financier a demandé que les stocks endommagés soient séparés avant le comptage.
Décision :
Aucun changement de date. Le stock endommagé sera étiqueté d'ici le 24 septembre.
Action :
Alex Reed coordonnera l'étiquetage du stock endommagé d'ici le 2026-09-24.
Autres sujets
Sofia a demandé que la couverture des vacances d'octobre soit ajoutée au prochain ordre du jour.
Résumé des décisions
- Maintenir l'objectif de niveau de service existant.
- Combler les manques du samedi avec du personnel à temps partiel formé.
- Maintenir la date de l'inventaire au 26 septembre.
Résumé du plan d'action
- Comparaison du temps de traitement - Responsable : Marcus Green - Échéance : 2026-09-22
- Planning du week-end de septembre - Responsable : Hana Kim - Échéance : 2026-09-11
- Étiquetage du stock endommagé - Responsable : Alex Reed - Échéance : 2026-09-24
Prochaine réunion
Date : 2026-09-15
Clôture
Heure : 14:50 (ET)
Procès-verbal rédigé par : Sofia Patel
Date : 2026-09-08
Heure : 14:00 - 14:50 (ET)
Lieu : Salle de conférence B / Teams
Président / Animateur : Jordan Lee
Secrétaire : Sofia Patel
Participants : Jordan Lee, Sofia Patel, Marcus Green, Hana Kim, Alex Reed
Absents : Aucun
Objectif de la réunion
Passer en revue les performances de traitement, les postes vacants et l'inventaire de septembre.
Point d'ordre du jour 1 : Performances de traitement
Résumé de la discussion :
Le temps moyen de traitement des commandes est passé de 7,8 à 9,1 heures la semaine dernière. Marcus a attribué cette hausse à deux arrivages tardifs et à une panne temporaire d'un poste d'emballage.
Décision :
Conserver l'objectif de niveau de service actuel et revoir après deux cycles d'expédition normaux.
Action :
Marcus Green fournira une comparaison du temps de traitement sur deux semaines avant le 2026-09-22.
Point d'ordre du jour 2 : Effectifs du week-end
Résumé de la discussion :
Le quart du samedi manque de deux personnes pour les trois prochains week-ends. Hana a confirmé que quatre employés à temps partiel sont disponibles.
Décision :
Proposer les quarts du samedi aux employés à temps partiel formés avant de demander des heures supplémentaires.
Action :
Hana Kim finalisera le planning du week-end de septembre d'ici le 2026-09-11.
Point d'ordre du jour 3 : Inventaire
Résumé de la discussion :
L'inventaire complet est maintenu au 26 septembre. Le service financier a demandé que les stocks endommagés soient séparés avant le comptage.
Décision :
Aucun changement de date. Le stock endommagé sera étiqueté d'ici le 24 septembre.
Action :
Alex Reed coordonnera l'étiquetage du stock endommagé d'ici le 2026-09-24.
Autres sujets
Sofia a demandé que la couverture des vacances d'octobre soit ajoutée au prochain ordre du jour.
Résumé des décisions
- Maintenir l'objectif de niveau de service existant.
- Combler les manques du samedi avec du personnel à temps partiel formé.
- Maintenir la date de l'inventaire au 26 septembre.
Résumé du plan d'action
- Comparaison du temps de traitement - Responsable : Marcus Green - Échéance : 2026-09-22
- Planning du week-end de septembre - Responsable : Hana Kim - Échéance : 2026-09-11
- Étiquetage du stock endommagé - Responsable : Alex Reed - Échéance : 2026-09-24
Prochaine réunion
Date : 2026-09-15
Clôture
Heure : 14:50 (ET)
Procès-verbal rédigé par : Sofia Patel
Modèle prêt pour l'IA
TÂCHE
Convertir la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme une action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser "Non spécifié" pour un champ requis manquant.
- Utiliser "Non résolu" pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, actions et questions en suspens séparées.
- Préserver les incertitudes et désaccords lorsqu'ils existent.
FORMAT DE SORTIE
Nom de la réunion : [ ]
Date : [ ]
Heure : [ ]
Lieu : [ ]
Président / Animateur : [ ]
Secrétaire : [ ]
Participants : [ ]
Absents : [ ]
Objectif de la réunion
[ ]
Point d'ordre du jour 1 : [ ]
Résumé de la discussion :
[ ]
Décision :
[ ]
Action :
[ ]
Autres sujets
[ ]
Résumé des décisions
- [ ]
Résumé du plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine réunion
Date : [ ]
Clôture
Heure : [ ]
Procès-verbal rédigé par : [ ]
Ne renvoyer que le modèle complété.
Convertir la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme une action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser "Non spécifié" pour un champ requis manquant.
- Utiliser "Non résolu" pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, actions et questions en suspens séparées.
- Préserver les incertitudes et désaccords lorsqu'ils existent.
FORMAT DE SORTIE
Nom de la réunion : [ ]
Date : [ ]
Heure : [ ]
Lieu : [ ]
Président / Animateur : [ ]
Secrétaire : [ ]
Participants : [ ]
Absents : [ ]
Objectif de la réunion
[ ]
Point d'ordre du jour 1 : [ ]
Résumé de la discussion :
[ ]
Décision :
[ ]
Action :
[ ]
Autres sujets
[ ]
Résumé des décisions
- [ ]
Résumé du plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine réunion
Date : [ ]
Clôture
Heure : [ ]
Procès-verbal rédigé par : [ ]
Ne renvoyer que le modèle complété.
3. Modèle de procès-verbal formel / de conseil d'administration
Modèle vierge
Organisation : [ ]
Type de réunion : [Conseil / Comité / Annuelle / Spéciale]
Date : [AAAA-MM-JJ]
Heure : [Début - Fin]
Lieu : [ ]
Président : [ ]
Secrétaire / Rédacteur : [ ]
Directeurs / Membres présents : [ ]
Directeurs / Membres absents : [ ]
Invités : [ ]
1. Ouverture de la séance
La réunion a été ouverte à [heure] par [nom].
2. Quorum
[Quorum confirmé / Non confirmé / Non spécifié]
3. Approbation du procès-verbal précédent
Motion / action : [ ]
Résultat : [ ]
4. Rapports
Rapport : [ ]
Résumé : [ ]
Action / Décision : [ ]
5. Affaires en suspens
Sujet : [ ]
Discussion : [ ]
Motion / Décision : [ ]
Vote / Résultat : [ ]
6. Nouvelles affaires
Sujet : [ ]
Discussion : [ ]
Motion : [Motion exacte, si énoncée]
Proposé par : [ ]
Appuyé par : [ ]
Vote : [ ]
Résultat : [Adopté / Rejeté / Reporté / Non spécifié]
7. Résolutions / Décisions
- [Résolution ou décision telle qu'approuvée]
8. Plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
9. Prochaine réunion
Date : [ ]
10. Clôture
La réunion a été close à [heure].
Rédigé par : [ ]
Approuvé par : [ ]
Date d'approbation : [ ]
Type de réunion : [Conseil / Comité / Annuelle / Spéciale]
Date : [AAAA-MM-JJ]
Heure : [Début - Fin]
Lieu : [ ]
Président : [ ]
Secrétaire / Rédacteur : [ ]
Directeurs / Membres présents : [ ]
Directeurs / Membres absents : [ ]
Invités : [ ]
1. Ouverture de la séance
La réunion a été ouverte à [heure] par [nom].
2. Quorum
[Quorum confirmé / Non confirmé / Non spécifié]
3. Approbation du procès-verbal précédent
Motion / action : [ ]
Résultat : [ ]
4. Rapports
Rapport : [ ]
Résumé : [ ]
Action / Décision : [ ]
5. Affaires en suspens
Sujet : [ ]
Discussion : [ ]
Motion / Décision : [ ]
Vote / Résultat : [ ]
6. Nouvelles affaires
Sujet : [ ]
Discussion : [ ]
Motion : [Motion exacte, si énoncée]
Proposé par : [ ]
Appuyé par : [ ]
Vote : [ ]
Résultat : [Adopté / Rejeté / Reporté / Non spécifié]
7. Résolutions / Décisions
- [Résolution ou décision telle qu'approuvée]
8. Plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
9. Prochaine réunion
Date : [ ]
10. Clôture
La réunion a été close à [heure].
Rédigé par : [ ]
Approuvé par : [ ]
Date d'approbation : [ ]
Exemple rempli
Organisation : Fondation des arts communautaires Harborview
Type de réunion : Réunion du conseil d'administration
Date : 2026-09-03
Heure : 18:00 - 19:18
Lieu : Centre d'arts Harborview, salle 204
Président : Elaine Brooks
Secrétaire / Rédacteur : Noah Bennett
Directeurs / Membres présents : Elaine Brooks, Noah Bennett, Carla Nguyen, Thomas Reed, Priya Nair
Directeurs / Membres absents : Javier Ortiz
Invités : Morgan Ellis, Directrice exécutive
1. Ouverture de la séance
La réunion a été ouverte à 18:00 par Elaine Brooks.
2. Quorum
Quorum confirmé.
3. Approbation du procès-verbal précédent
Motion / action : Carla Nguyen a proposé d'approuver le procès-verbal du 6 août 2026 tel que diffusé. Thomas Reed a appuyé la motion.
Résultat : Motion adoptée à l'unanimité.
4. Rapports
Rapport : Rapport de la directrice exécutive
Résumé : Morgan Ellis a indiqué que les inscriptions au programme d'été ont atteint 412 participants et que deux ateliers d'automne restent en dessous des objectifs.
Action / Décision : Le personnel consolidera les deux ateliers si l'effectif total reste inférieur à 18 le 15 septembre.
5. Affaires en suspens
Sujet : Contrat de réparation du toit
Discussion : Le conseil a examiné deux soumissions révisées. Le comité des finances a recommandé la proposition de 42 800 $ de Cedar Construction car elle inclut la réparation du drainage et une garantie décennale.
Motion / Décision : Approuver la proposition de Cedar Construction pour 42 800 $, sous réserve d'une vérification d'assurance finale.
Vote / Résultat : 5 pour, 0 contre. Motion adoptée.
6. Nouvelles affaires
Sujet : Date du gala de collecte de fonds 2027
Discussion : Le conseil a discuté de la disponibilité du lieu pour le 17 et le 24 avril.
Motion : Réserver le 24 avril 2027 pour le gala et autoriser un dépôt de garantie jusqu'à 5 000 $.
Proposé par : Priya Nair
Appuyé par : Noah Bennett
Vote : 5 pour, 0 contre
Résultat : Adopté
7. Résolutions / Décisions
- Approuver la proposition de réparation de toit de Cedar Construction pour 42 800 $, sous réserve de vérification d'assurance.
- Réserver le 24 avril 2027 pour le gala et autoriser un dépôt jusqu'à 5 000 $.
8. Plan d'action
- Vérifier les documents d'assurance de Cedar Construction - Responsable : Morgan Ellis - Échéance : 2026-09-10
- Réserver le lieu du gala et confirmer les conditions de dépôt - Responsable : Priya Nair - Échéance : 2026-09-18
9. Prochaine réunion
Date : 2026-10-01
10. Clôture
La réunion a été close à 19:18.
Rédigé par : Noah Bennett
Approuvé par : Non spécifié
Date d'approbation : Non spécifié
Type de réunion : Réunion du conseil d'administration
Date : 2026-09-03
Heure : 18:00 - 19:18
Lieu : Centre d'arts Harborview, salle 204
Président : Elaine Brooks
Secrétaire / Rédacteur : Noah Bennett
Directeurs / Membres présents : Elaine Brooks, Noah Bennett, Carla Nguyen, Thomas Reed, Priya Nair
Directeurs / Membres absents : Javier Ortiz
Invités : Morgan Ellis, Directrice exécutive
1. Ouverture de la séance
La réunion a été ouverte à 18:00 par Elaine Brooks.
2. Quorum
Quorum confirmé.
3. Approbation du procès-verbal précédent
Motion / action : Carla Nguyen a proposé d'approuver le procès-verbal du 6 août 2026 tel que diffusé. Thomas Reed a appuyé la motion.
Résultat : Motion adoptée à l'unanimité.
4. Rapports
Rapport : Rapport de la directrice exécutive
Résumé : Morgan Ellis a indiqué que les inscriptions au programme d'été ont atteint 412 participants et que deux ateliers d'automne restent en dessous des objectifs.
Action / Décision : Le personnel consolidera les deux ateliers si l'effectif total reste inférieur à 18 le 15 septembre.
5. Affaires en suspens
Sujet : Contrat de réparation du toit
Discussion : Le conseil a examiné deux soumissions révisées. Le comité des finances a recommandé la proposition de 42 800 $ de Cedar Construction car elle inclut la réparation du drainage et une garantie décennale.
Motion / Décision : Approuver la proposition de Cedar Construction pour 42 800 $, sous réserve d'une vérification d'assurance finale.
Vote / Résultat : 5 pour, 0 contre. Motion adoptée.
6. Nouvelles affaires
Sujet : Date du gala de collecte de fonds 2027
Discussion : Le conseil a discuté de la disponibilité du lieu pour le 17 et le 24 avril.
Motion : Réserver le 24 avril 2027 pour le gala et autoriser un dépôt de garantie jusqu'à 5 000 $.
Proposé par : Priya Nair
Appuyé par : Noah Bennett
Vote : 5 pour, 0 contre
Résultat : Adopté
7. Résolutions / Décisions
- Approuver la proposition de réparation de toit de Cedar Construction pour 42 800 $, sous réserve de vérification d'assurance.
- Réserver le 24 avril 2027 pour le gala et autoriser un dépôt jusqu'à 5 000 $.
8. Plan d'action
- Vérifier les documents d'assurance de Cedar Construction - Responsable : Morgan Ellis - Échéance : 2026-09-10
- Réserver le lieu du gala et confirmer les conditions de dépôt - Responsable : Priya Nair - Échéance : 2026-09-18
9. Prochaine réunion
Date : 2026-10-01
10. Clôture
La réunion a été close à 19:18.
Rédigé par : Noah Bennett
Approuvé par : Non spécifié
Date d'approbation : Non spécifié
Modèle prêt pour l'IA
TÂCHE
Convertir la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme une action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser "Non spécifié" pour un champ requis manquant.
- Utiliser "Non résolu" pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, actions et questions en suspens séparées.
- Préserver les incertitudes et désaccords lorsqu'ils existent.
RÈGLES DE PROCÈS-VERBAL FORMEL
- Enregistrer une motion, un appui, un vote, une résolution ou un quorum seulement quand la source le mentionne explicitement.
- Préserver la substance exacte des motions ; ne pas transformer un accord informel en motion formelle.
FORMAT DE SORTIE
Organisation : [ ]
Type de réunion : [ ]
Date : [ ]
Heure : [ ]
Lieu : [ ]
Président : [ ]
Secrétaire / Rédacteur : [ ]
Directeurs / Membres présents : [ ]
Directeurs / Membres absents : [ ]
Invités : [ ]
1. Ouverture de la séance
[ ]
2. Quorum
[ ]
3. Approbation du procès-verbal précédent
Motion / action : [ ]
Résultat : [ ]
4. Rapports
Rapport : [ ]
Résumé : [ ]
Action / Décision : [ ]
5. Affaires en suspens
Sujet : [ ]
Discussion : [ ]
Motion / Décision : [ ]
Vote / Résultat : [ ]
6. Nouvelles affaires
Sujet : [ ]
Discussion : [ ]
Motion : [ ]
Proposé par : [ ]
Appuyé par : [ ]
Vote : [ ]
Résultat : [ ]
7. Résolutions / Décisions
- [ ]
8. Plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
9. Prochaine réunion
Date : [ ]
10. Clôture
[ ]
Rédigé par : [ ]
Approuvé par : [ ]
Date d'approbation : [ ]
Ne renvoyer que le modèle complété.
Convertir la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme une action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser "Non spécifié" pour un champ requis manquant.
- Utiliser "Non résolu" pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, actions et questions en suspens séparées.
- Préserver les incertitudes et désaccords lorsqu'ils existent.
RÈGLES DE PROCÈS-VERBAL FORMEL
- Enregistrer une motion, un appui, un vote, une résolution ou un quorum seulement quand la source le mentionne explicitement.
- Préserver la substance exacte des motions ; ne pas transformer un accord informel en motion formelle.
FORMAT DE SORTIE
Organisation : [ ]
Type de réunion : [ ]
Date : [ ]
Heure : [ ]
Lieu : [ ]
Président : [ ]
Secrétaire / Rédacteur : [ ]
Directeurs / Membres présents : [ ]
Directeurs / Membres absents : [ ]
Invités : [ ]
1. Ouverture de la séance
[ ]
2. Quorum
[ ]
3. Approbation du procès-verbal précédent
Motion / action : [ ]
Résultat : [ ]
4. Rapports
Rapport : [ ]
Résumé : [ ]
Action / Décision : [ ]
5. Affaires en suspens
Sujet : [ ]
Discussion : [ ]
Motion / Décision : [ ]
Vote / Résultat : [ ]
6. Nouvelles affaires
Sujet : [ ]
Discussion : [ ]
Motion : [ ]
Proposé par : [ ]
Appuyé par : [ ]
Vote : [ ]
Résultat : [ ]
7. Résolutions / Décisions
- [ ]
8. Plan d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
9. Prochaine réunion
Date : [ ]
10. Clôture
[ ]
Rédigé par : [ ]
Approuvé par : [ ]
Date d'approbation : [ ]
Ne renvoyer que le modèle complété.
4. Modèle de notes de réunion individuelle (1:1)
Modèle vierge
1:1 : [Manager] + [Membre de l'équipe]
Date : [AAAA-MM-JJ]
Heure : [ ]
Check-in
- Énergie / charge de travail : [ ]
- Urgences : [ ]
Succès depuis le dernier 1:1
- [ ]
Priorités actuelles
- [Priorité] - Statut : [ ]
Obstacles
- [ ]
Besoin de soutien du manager
- [ ]
Feedback pour le membre de l'équipe
- [Comportement spécifique / résultat / contexte]
Feedback pour le manager
- [ ]
Carrière / Développement
- Objectif : [ ]
- Compétence / expérience à acquérir : [ ]
- Opportunité / étape suivante : [ ]
Sujets que le membre de l'équipe souhaite aborder
- [ ]
Décisions
- [ ]
Engagements / Suivi
- [Engagement] - Responsable : [ ] - Échéance : [ ]
Sujets pour le prochain 1:1
- [ ]
Date : [AAAA-MM-JJ]
Heure : [ ]
Check-in
- Énergie / charge de travail : [ ]
- Urgences : [ ]
Succès depuis le dernier 1:1
- [ ]
Priorités actuelles
- [Priorité] - Statut : [ ]
Obstacles
- [ ]
Besoin de soutien du manager
- [ ]
Feedback pour le membre de l'équipe
- [Comportement spécifique / résultat / contexte]
Feedback pour le manager
- [ ]
Carrière / Développement
- Objectif : [ ]
- Compétence / expérience à acquérir : [ ]
- Opportunité / étape suivante : [ ]
Sujets que le membre de l'équipe souhaite aborder
- [ ]
Décisions
- [ ]
Engagements / Suivi
- [Engagement] - Responsable : [ ] - Échéance : [ ]
Sujets pour le prochain 1:1
- [ ]
Client : [ ]
Réunion : [ ]
Date : [AAAA-MM-JJ]
Participants - Client : [ ]
Participants - Interne : [ ]
Objectif de la réunion : [ ]
Statut actuel
- [ ]
Priorités du client
- [ ]
Retours du client
- Positifs : [ ]
- Préoccupations : [ ]
Requêtes
- [Requête] - Priorité : [ ]
Livrables discutés
- [Livrable] - Statut : [ ] - Date cible : [ ]
Modifications demandées
- [Modification] - Approuvée / En attente / Rejetée : [ ]
Risques / Préoccupations
- [ ]
Décisions
- [ ]
Engagements du client
- [ ]
Engagements internes
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochain point de contact
Date : [ ]
Objectif : [ ]
Réunion : [ ]
Date : [AAAA-MM-JJ]
Participants - Client : [ ]
Participants - Interne : [ ]
Objectif de la réunion : [ ]
Statut actuel
- [ ]
Priorités du client
- [ ]
Retours du client
- Positifs : [ ]
- Préoccupations : [ ]
Requêtes
- [Requête] - Priorité : [ ]
Livrables discutés
- [Livrable] - Statut : [ ] - Date cible : [ ]
Modifications demandées
- [Modification] - Approuvée / En attente / Rejetée : [ ]
Risques / Préoccupations
- [ ]
Décisions
- [ ]
Engagements du client
- [ ]
Engagements internes
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochain point de contact
Date : [ ]
Objectif : [ ]
Exemple rempli
Client : Brightline Health
Réunion : Revue de mise en œuvre de septembre
Date : 2026-09-10
Participants - Client : Melissa Grant, Kevin Wu
Participants - Interne : Nora Fields, Henry Cole, James Park
Objectif de la réunion : Examiner l'état de la mise en œuvre, confirmer les dates de formation et résoudre le problème d'importation de données.
Statut actuel
- La configuration de base est terminée.
- 87 % des enregistrements historiques ont été importés avec succès.
- Les tests d'acceptation utilisateur (UAT) débutent le 21 septembre.
Priorités du client
- Terminer l'importation des données historiques restantes avant l'UAT.
- Former l'équipe de support avant le lancement du 5 octobre.
- Éviter toute modification du flux de connexion côté client avant le lancement.
Retours du client
- Positifs : Melissa a indiqué que la configuration des autorisations est plus claire que dans l'ancien système.
- Préoccupations : Kevin craint que les lignes d'importation rejetées ne contiennent pas suffisamment de détails sur les erreurs pour que son équipe puisse les corriger rapidement.
Requêtes
- Ajouter les motifs d'erreur au niveau de la ligne dans l'export des enregistrements rejetés - Priorité : Haute
- Fournir une liste de vérification pour la réinitialisation de l'environnement de bac à sable (sandbox) - Priorité : Moyenne
Livrables discutés
- Importation des données historiques - Statut : 87 % terminé - Date cible : 2026-09-18
- Support de formation administrateur - Statut : Brouillon - Date cible : 2026-09-23
Modifications demandées
- Ajouter des motifs détaillés d'erreur d'importation - Approuvée / En attente / Rejetée : En attente d'estimation technique
- Modifier la mise en page de la page de connexion - Approuvée / En attente / Rejetée : Rejetée pour le périmètre pré-lancement ; à revoir après le lancement
Risques / Préoccupations
- Le nettoyage des données importées pourrait retarder l'UAT si les lignes rejetées ne sont pas résolues d'ici le 18 septembre.
Décisions
- Maintenir la date de lancement au 5 octobre.
- Ne pas modifier la page de connexion avant le lancement.
Engagements du client
- Kevin enverra trois exemples de lignes rejetées d'ici le 11 septembre.
Engagements internes
- Henry fournira une estimation pour les motifs d'erreur détaillés lors de l'importation.
- Nora enverra la liste de vérification pour la réinitialisation du bac à sable.
Points d'action
- Envoyer des exemples de lignes rejetées - Responsable : Kevin Wu - Échéance : 2026-09-11
- Estimer l'amélioration des erreurs d'importation - Responsable : Henry Cole - Échéance : 2026-09-14
- Envoyer la liste de vérification de réinitialisation du bac à sable - Responsable : Nora Fields - Échéance : 2026-09-12
Prochain point de contact
Date : 2026-09-17
Objectif : Préparation de l'importation et revue « go/no-go » pour l'UAT.
Réunion : Revue de mise en œuvre de septembre
Date : 2026-09-10
Participants - Client : Melissa Grant, Kevin Wu
Participants - Interne : Nora Fields, Henry Cole, James Park
Objectif de la réunion : Examiner l'état de la mise en œuvre, confirmer les dates de formation et résoudre le problème d'importation de données.
Statut actuel
- La configuration de base est terminée.
- 87 % des enregistrements historiques ont été importés avec succès.
- Les tests d'acceptation utilisateur (UAT) débutent le 21 septembre.
Priorités du client
- Terminer l'importation des données historiques restantes avant l'UAT.
- Former l'équipe de support avant le lancement du 5 octobre.
- Éviter toute modification du flux de connexion côté client avant le lancement.
Retours du client
- Positifs : Melissa a indiqué que la configuration des autorisations est plus claire que dans l'ancien système.
- Préoccupations : Kevin craint que les lignes d'importation rejetées ne contiennent pas suffisamment de détails sur les erreurs pour que son équipe puisse les corriger rapidement.
Requêtes
- Ajouter les motifs d'erreur au niveau de la ligne dans l'export des enregistrements rejetés - Priorité : Haute
- Fournir une liste de vérification pour la réinitialisation de l'environnement de bac à sable (sandbox) - Priorité : Moyenne
Livrables discutés
- Importation des données historiques - Statut : 87 % terminé - Date cible : 2026-09-18
- Support de formation administrateur - Statut : Brouillon - Date cible : 2026-09-23
Modifications demandées
- Ajouter des motifs détaillés d'erreur d'importation - Approuvée / En attente / Rejetée : En attente d'estimation technique
- Modifier la mise en page de la page de connexion - Approuvée / En attente / Rejetée : Rejetée pour le périmètre pré-lancement ; à revoir après le lancement
Risques / Préoccupations
- Le nettoyage des données importées pourrait retarder l'UAT si les lignes rejetées ne sont pas résolues d'ici le 18 septembre.
Décisions
- Maintenir la date de lancement au 5 octobre.
- Ne pas modifier la page de connexion avant le lancement.
Engagements du client
- Kevin enverra trois exemples de lignes rejetées d'ici le 11 septembre.
Engagements internes
- Henry fournira une estimation pour les motifs d'erreur détaillés lors de l'importation.
- Nora enverra la liste de vérification pour la réinitialisation du bac à sable.
Points d'action
- Envoyer des exemples de lignes rejetées - Responsable : Kevin Wu - Échéance : 2026-09-11
- Estimer l'amélioration des erreurs d'importation - Responsable : Henry Cole - Échéance : 2026-09-14
- Envoyer la liste de vérification de réinitialisation du bac à sable - Responsable : Nora Fields - Échéance : 2026-09-12
Prochain point de contact
Date : 2026-09-17
Objectif : Préparation de l'importation et revue « go/no-go » pour l'UAT.
Modèle prêt pour l'IA
TÂCHE
Convertir la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme un point d'action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser « Non spécifié » pour un champ requis manquant.
- Utiliser « Non résolu » pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, points d'action et questions en suspens séparés.
- Préserver les incertitudes et les désaccords lorsqu'ils existent.
RÈGLES POUR LES RÉUNIONS CLIENT
- Distinguer les requêtes des modifications de périmètre approuvées.
- Ne pas décrire une requête comme un travail engagé sauf si l'approbation est explicite.
- Garder les engagements du client et les engagements internes séparés.
FORMAT DE SORTIE
Client : [ ]
Réunion : [ ]
Date : [ ]
Participants - Client : [ ]
Participants - Interne : [ ]
Objectif de la réunion : [ ]
Statut actuel
- [ ]
Priorités du client
- [ ]
Retours du client
- Positifs : [ ]
- Préoccupations : [ ]
Requêtes
- [Requête] - Priorité : [ ]
Livrables discutés
- [Livrable] - Statut : [ ] - Date cible : [ ]
Modifications demandées
- [Modification] - Approuvée / En attente / Rejetée : [ ]
Risques / Préoccupations
- [ ]
Décisions
- [ ]
Engagements du client
- [ ]
Engagements internes
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochain point de contact
Date : [ ]
Objectif : [ ]
Ne retourner que le modèle complété.
Convertir la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme un point d'action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser « Non spécifié » pour un champ requis manquant.
- Utiliser « Non résolu » pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, points d'action et questions en suspens séparés.
- Préserver les incertitudes et les désaccords lorsqu'ils existent.
RÈGLES POUR LES RÉUNIONS CLIENT
- Distinguer les requêtes des modifications de périmètre approuvées.
- Ne pas décrire une requête comme un travail engagé sauf si l'approbation est explicite.
- Garder les engagements du client et les engagements internes séparés.
FORMAT DE SORTIE
Client : [ ]
Réunion : [ ]
Date : [ ]
Participants - Client : [ ]
Participants - Interne : [ ]
Objectif de la réunion : [ ]
Statut actuel
- [ ]
Priorités du client
- [ ]
Retours du client
- Positifs : [ ]
- Préoccupations : [ ]
Requêtes
- [Requête] - Priorité : [ ]
Livrables discutés
- [Livrable] - Statut : [ ] - Date cible : [ ]
Modifications demandées
- [Modification] - Approuvée / En attente / Rejetée : [ ]
Risques / Préoccupations
- [ ]
Décisions
- [ ]
Engagements du client
- [ ]
Engagements internes
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochain point de contact
Date : [ ]
Objectif : [ ]
Ne retourner que le modèle complété.
9. Modèle de revue de projet / réunion de suivi de projet
Modèle vierge
Projet : [ ]
Période de revue : [ ]
Date : [AAAA-MM-JJ]
Responsable du projet : [ ]
Participants : [ ]
Statut global : [En bonne voie / À risque / En retard / Non précisé]
Objectif du projet
[ ]
Jalons
- [Jalon] - Cible : [ ] - Statut : [ ]
Réalisé depuis la dernière revue
- [ ]
En cours
- [ ]
À venir
- [ ]
État du calendrier
[ ]
Budget / Ressources
[ ]
Risques
- [Risque] - Probabilité / impact si précisé : [ ] - Atténuation : [ ]
Problèmes / Bloquants
- [Problème] - Responsable : [ ]
Dépendances
- [Dépendance] - Responsable / équipe : [ ]
Modifications de périmètre
- [Modification] - Statut : [Proposée / Approuvée / Rejetée]
Décisions nécessaires
- [ ]
Décisions prises
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine revue
Date : [ ]
Focus : [ ]
Période de revue : [ ]
Date : [AAAA-MM-JJ]
Responsable du projet : [ ]
Participants : [ ]
Statut global : [En bonne voie / À risque / En retard / Non précisé]
Objectif du projet
[ ]
Jalons
- [Jalon] - Cible : [ ] - Statut : [ ]
Réalisé depuis la dernière revue
- [ ]
En cours
- [ ]
À venir
- [ ]
État du calendrier
[ ]
Budget / Ressources
[ ]
Risques
- [Risque] - Probabilité / impact si précisé : [ ] - Atténuation : [ ]
Problèmes / Bloquants
- [Problème] - Responsable : [ ]
Dépendances
- [Dépendance] - Responsable / équipe : [ ]
Modifications de périmètre
- [Modification] - Statut : [Proposée / Approuvée / Rejetée]
Décisions nécessaires
- [ ]
Décisions prises
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine revue
Date : [ ]
Focus : [ ]
Exemple rempli
Projet : Refonte du portail client
Période de revue : Sprint 2 de septembre
Date : 2026-09-09
Responsable du projet : Carmen Lewis
Participants : Carmen Lewis, Dev Shah, Iris Wong, Taylor Moore, Luis Rivera
Statut global : À risque
Objectif du projet
Lancer le portail client refondu d'ici le 2 novembre avec une facturation consolidée, un historique de support et des flux de gestion de compte.
Jalons
- Système de conception terminé - Cible : 2026-08-28 - Statut : Terminé
- Intégration de la facturation terminée - Cible : 2026-09-18 - Statut : À risque
- Version bêta - Cible : 2026-10-05 - Statut : Non commencé
- Version générale - Cible : 2026-11-02 - Statut : Non commencé
Réalisé depuis la dernière revue
- Finalisation de la navigation du compte.
- Intégration de l'API d'historique de support terminée.
- Revue d'accessibilité du flux de profil terminée.
En cours
- Intégration de l'API de facturation.
- Refonte du PDF de facture.
- Recrutement de clients pour la version bêta.
À venir
- Test de bout en bout de la facturation.
- Configuration de l'environnement bêta.
- Brouillon de la formation du support client.
État du calendrier
L'intégration de la facturation accuse quatre jours ouvrables de retard par rapport au plan interne car le bac à sable n'incluait pas deux états de facture requis. La date de lancement du 2 novembre n'a pas été modifiée.
Budget / Ressources
Aucun écart budgétaire n'a été signalé. Dev a demandé un ingénieur backend supplémentaire pour trois jours afin de récupérer le calendrier de facturation.
Risques
- Retard de l'API de facturation - Probabilité / impact si précisé : Impact élevé - Atténuation : Ajouter une capacité d'ingénierie temporaire et terminer les correctifs du bac à sable.
- Recrutement bêta inférieur à l'objectif - Probabilité / impact si précisé : Non spécifié - Atténuation : Le Customer Success invitera dix comptes supplémentaires.
Problèmes / Bloquants
- États de facture manquants dans le bac à sable de facturation - Responsable : Dev Shah
Dépendances
- Mise à jour du bac à sable de facturation - Responsable / équipe : Plateforme financière
- Liste des comptes bêta - Responsable / équipe : Customer Success
Modifications de périmètre
- Ajouter un CSV d'utilisation téléchargeable à la version bêta - Statut : Proposé
Décisions nécessaires
- Décider si le CSV d'utilisation téléchargeable doit être inclus dans le périmètre bêta.
Décisions prises
- Ajouter un ingénieur backend pour trois jours afin de récupérer le calendrier de facturation.
Points d'action
- Obtenir un support backend temporaire - Responsable : Carmen Lewis - Échéance : 2026-09-10
- Fournir les correctifs de bac à sable manquants - Responsable : Dev Shah - Échéance : 2026-09-11
- Inviter dix comptes bêta supplémentaires - Responsable : Taylor Moore - Échéance : 2026-09-14
Prochaine revue
Date : 2026-09-16
Focus : Récupération de la facturation et préparation de la version bêta.
Période de revue : Sprint 2 de septembre
Date : 2026-09-09
Responsable du projet : Carmen Lewis
Participants : Carmen Lewis, Dev Shah, Iris Wong, Taylor Moore, Luis Rivera
Statut global : À risque
Objectif du projet
Lancer le portail client refondu d'ici le 2 novembre avec une facturation consolidée, un historique de support et des flux de gestion de compte.
Jalons
- Système de conception terminé - Cible : 2026-08-28 - Statut : Terminé
- Intégration de la facturation terminée - Cible : 2026-09-18 - Statut : À risque
- Version bêta - Cible : 2026-10-05 - Statut : Non commencé
- Version générale - Cible : 2026-11-02 - Statut : Non commencé
Réalisé depuis la dernière revue
- Finalisation de la navigation du compte.
- Intégration de l'API d'historique de support terminée.
- Revue d'accessibilité du flux de profil terminée.
En cours
- Intégration de l'API de facturation.
- Refonte du PDF de facture.
- Recrutement de clients pour la version bêta.
À venir
- Test de bout en bout de la facturation.
- Configuration de l'environnement bêta.
- Brouillon de la formation du support client.
État du calendrier
L'intégration de la facturation accuse quatre jours ouvrables de retard par rapport au plan interne car le bac à sable n'incluait pas deux états de facture requis. La date de lancement du 2 novembre n'a pas été modifiée.
Budget / Ressources
Aucun écart budgétaire n'a été signalé. Dev a demandé un ingénieur backend supplémentaire pour trois jours afin de récupérer le calendrier de facturation.
Risques
- Retard de l'API de facturation - Probabilité / impact si précisé : Impact élevé - Atténuation : Ajouter une capacité d'ingénierie temporaire et terminer les correctifs du bac à sable.
- Recrutement bêta inférieur à l'objectif - Probabilité / impact si précisé : Non spécifié - Atténuation : Le Customer Success invitera dix comptes supplémentaires.
Problèmes / Bloquants
- États de facture manquants dans le bac à sable de facturation - Responsable : Dev Shah
Dépendances
- Mise à jour du bac à sable de facturation - Responsable / équipe : Plateforme financière
- Liste des comptes bêta - Responsable / équipe : Customer Success
Modifications de périmètre
- Ajouter un CSV d'utilisation téléchargeable à la version bêta - Statut : Proposé
Décisions nécessaires
- Décider si le CSV d'utilisation téléchargeable doit être inclus dans le périmètre bêta.
Décisions prises
- Ajouter un ingénieur backend pour trois jours afin de récupérer le calendrier de facturation.
Points d'action
- Obtenir un support backend temporaire - Responsable : Carmen Lewis - Échéance : 2026-09-10
- Fournir les correctifs de bac à sable manquants - Responsable : Dev Shah - Échéance : 2026-09-11
- Inviter dix comptes bêta supplémentaires - Responsable : Taylor Moore - Échéance : 2026-09-14
Prochaine revue
Date : 2026-09-16
Focus : Récupération de la facturation et préparation de la version bêta.
Modèle prêt pour l'IA
TÂCHE
Convertir la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme un point d'action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser « Non spécifié » pour un champ requis manquant.
- Utiliser « Non résolu » pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, points d'action et questions en suspens séparés.
- Préserver les incertitudes et les désaccords lorsqu'ils existent.
RÈGLES POUR LES REVUES DE PROJET
- Utiliser le statut de projet déclaré. Ne pas calculer ou déduire de statut Rouge/Orange/Vert sauf si la source définit la règle.
- Séparer les risques (problèmes futurs possibles) des problèmes/bloquants (problèmes actuels).
- Garder les modifications de périmètre proposées séparées des modifications approuvées.
FORMAT DE SORTIE
Projet : [ ]
Période de revue : [ ]
Date : [ ]
Responsable du projet : [ ]
Participants : [ ]
Statut global : [ ]
Objectif du projet
[ ]
Jalons
- [Jalon] - Cible : [ ] - Statut : [ ]
Réalisé depuis la dernière revue
- [ ]
En cours
- [ ]
À venir
- [ ]
État du calendrier
[ ]
Budget / Ressources
[ ]
Risques
- [Risque] - Probabilité / impact si précisé : [ ] - Atténuation : [ ]
Problèmes / Bloquants
- [Problème] - Responsable : [ ]
Dépendances
- [Dépendance] - Responsable / équipe : [ ]
Modifications de périmètre
- [Modification] - Statut : [ ]
Décisions nécessaires
- [ ]
Décisions prises
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine revue
Date : [ ]
Focus : [ ]
Ne retourner que le modèle complété.
Convertir la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme un point d'action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser « Non spécifié » pour un champ requis manquant.
- Utiliser « Non résolu » pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, points d'action et questions en suspens séparés.
- Préserver les incertitudes et les désaccords lorsqu'ils existent.
RÈGLES POUR LES REVUES DE PROJET
- Utiliser le statut de projet déclaré. Ne pas calculer ou déduire de statut Rouge/Orange/Vert sauf si la source définit la règle.
- Séparer les risques (problèmes futurs possibles) des problèmes/bloquants (problèmes actuels).
- Garder les modifications de périmètre proposées séparées des modifications approuvées.
FORMAT DE SORTIE
Projet : [ ]
Période de revue : [ ]
Date : [ ]
Responsable du projet : [ ]
Participants : [ ]
Statut global : [ ]
Objectif du projet
[ ]
Jalons
- [Jalon] - Cible : [ ] - Statut : [ ]
Réalisé depuis la dernière revue
- [ ]
En cours
- [ ]
À venir
- [ ]
État du calendrier
[ ]
Budget / Ressources
[ ]
Risques
- [Risque] - Probabilité / impact si précisé : [ ] - Atténuation : [ ]
Problèmes / Bloquants
- [Problème] - Responsable : [ ]
Dépendances
- [Dépendance] - Responsable / équipe : [ ]
Modifications de périmètre
- [Modification] - Statut : [ ]
Décisions nécessaires
- [ ]
Décisions prises
- [ ]
Points d'action
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Prochaine revue
Date : [ ]
Focus : [ ]
Ne retourner que le modèle complété.
10. Modèle de notes de réunion de lancement de projet
Modèle vierge
Projet : [ ]
Date de lancement : [AAAA-MM-JJ]
Chef de projet : [ ]
Sponsor : [ ]
Participants : [ ]
Objectif métier
[ ]
Critères de succès
- [ ]
Périmètre - Inclus
- [ ]
Périmètre - Exclu
- [ ]
Parties prenantes
- [Nom / rôle / responsabilité]
Rôles / Responsabilités
- [Personne / équipe] : [Responsabilité]
Livrables clés
- [Livrable] - Responsable : [ ] - Cible : [ ]
Jalons
- [Jalon] - Date cible : [ ]
Dépendances
- [ ]
Risques / Hypothèses
- Risque : [ ]
- Hypothèse : [ ]
Accords de travail
- [ ]
Rythme de communication
- [Réunion / canal / fréquence]
Processus décisionnel
[ ]
Questions en suspens
- [ ]
Points d'action initiaux
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Date de lancement : [AAAA-MM-JJ]
Chef de projet : [ ]
Sponsor : [ ]
Participants : [ ]
Objectif métier
[ ]
Critères de succès
- [ ]
Périmètre - Inclus
- [ ]
Périmètre - Exclu
- [ ]
Parties prenantes
- [Nom / rôle / responsabilité]
Rôles / Responsabilités
- [Personne / équipe] : [Responsabilité]
Livrables clés
- [Livrable] - Responsable : [ ] - Cible : [ ]
Jalons
- [Jalon] - Date cible : [ ]
Dépendances
- [ ]
Risques / Hypothèses
- Risque : [ ]
- Hypothèse : [ ]
Accords de travail
- [ ]
Rythme de communication
- [Réunion / canal / fréquence]
Processus décisionnel
[ ]
Questions en suspens
- [ ]
Points d'action initiaux
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Exemple rempli
Projet : Automatisation des rapports financiers
Date de lancement : 2026-09-07
Chef de projet : Maya Torres
Sponsor : Daniel Brooks, DAF
Participants : Maya Torres, Daniel Brooks, Nina Patel, Chris Allen, Victor Chen, Laura Perez
Objectif métier
Réduire le temps de préparation manuelle du rapport de gestion mensuel et créer une source unique contrôlée pour les métriques financières récurrentes.
Critères de succès
- Rapport de gestion mensuel généré dans un délai d'un jour ouvrable après la clôture.
- Aucune saisie manuelle de valeurs ERP approuvées dans le support de gestion.
- L'équipe Finance peut retracer chaque métrique rapportée jusqu'à sa table source.
Périmètre - Inclus
- Revenus, marge brute, dépenses d'exploitation, effectifs et métriques de trésorerie.
- Extraction automatique des données depuis l'ERP et le SIRH.
- Support de gestion mensuel standard.
Périmètre - Exclu
- Refonte du modèle de prévision.
- Refonte du support pour le conseil d'administration.
- Flux de travail budgétaire par département.
Parties prenantes
- Daniel Brooks - Sponsor exécutif.
- Nina Patel - Responsable du processus financier.
- Chris Allen - Responsable de l'ingénierie des données.
- Victor Chen - Revue de sécurité.
Rôles / Responsabilités
- Maya Torres : Coordination du projet et contrôle du périmètre.
- Nina Patel : Définitions des métriques et tests d'acceptation.
- Chris Allen : Pipeline de données et validation.
- Victor Chen : Revue des accès et de la sécurité.
Livrables clés
- Dictionnaire des métriques - Responsable : Nina Patel - Cible : 2026-09-18
- Pipeline de données automatisé - Responsable : Chris Allen - Cible : 2026-10-09
- Prototype du support de gestion - Responsable : Maya Torres - Cible : 2026-10-16
Jalons
- Validation des exigences - Date cible : 2026-09-18
- Premier test de bout en bout - Date cible : 2026-10-12
- Cycle de reporting parallèle - Date cible : 2026-11-02
Dépendances
- Accès API lecture seule à l'ERP.
- Mappage des champs SIRH.
- Approbation des définitions de métriques par la Finance.
Risques / Hypothèses
- Risque : Les limites de débit de l'API ERP peuvent ralentir la première extraction de données.
- Hypothèse : Les définitions des métriques mensuelles existantes resteront inchangées durant le projet pilote.
Accords de travail
- Les modifications de périmètre nécessitent une approbation écrite de Maya et Nina.
- Les questions de définition des données seront consignées dans le canal projet, pas résolues par messages privés.
Rythme de communication
- Point de synchronisation projet de 30 minutes chaque mardi.
- Mise à jour écrite sur le statut chaque vendredi.
Processus décisionnel
Les décisions de processus sont prises par Nina ; les décisions d'implémentation technique sont prises par Chris ; les modifications de périmètre nécessitent l'approbation de Maya et Nina.
Questions en suspens
- La variance des prévisions de trésorerie doit-elle figurer dans la première version ?
Points d'action initiaux
- Rédiger le dictionnaire des métriques - Responsable : Nina Patel - Échéance : 2026-09-11
- Demander l'accès API à l'ERP - Responsable : Chris Allen - Échéance : 2026-09-09
- Créer le registre des risques du projet - Responsable : Maya Torres - Échéance : 2026-09-09
Date de lancement : 2026-09-07
Chef de projet : Maya Torres
Sponsor : Daniel Brooks, DAF
Participants : Maya Torres, Daniel Brooks, Nina Patel, Chris Allen, Victor Chen, Laura Perez
Objectif métier
Réduire le temps de préparation manuelle du rapport de gestion mensuel et créer une source unique contrôlée pour les métriques financières récurrentes.
Critères de succès
- Rapport de gestion mensuel généré dans un délai d'un jour ouvrable après la clôture.
- Aucune saisie manuelle de valeurs ERP approuvées dans le support de gestion.
- L'équipe Finance peut retracer chaque métrique rapportée jusqu'à sa table source.
Périmètre - Inclus
- Revenus, marge brute, dépenses d'exploitation, effectifs et métriques de trésorerie.
- Extraction automatique des données depuis l'ERP et le SIRH.
- Support de gestion mensuel standard.
Périmètre - Exclu
- Refonte du modèle de prévision.
- Refonte du support pour le conseil d'administration.
- Flux de travail budgétaire par département.
Parties prenantes
- Daniel Brooks - Sponsor exécutif.
- Nina Patel - Responsable du processus financier.
- Chris Allen - Responsable de l'ingénierie des données.
- Victor Chen - Revue de sécurité.
Rôles / Responsabilités
- Maya Torres : Coordination du projet et contrôle du périmètre.
- Nina Patel : Définitions des métriques et tests d'acceptation.
- Chris Allen : Pipeline de données et validation.
- Victor Chen : Revue des accès et de la sécurité.
Livrables clés
- Dictionnaire des métriques - Responsable : Nina Patel - Cible : 2026-09-18
- Pipeline de données automatisé - Responsable : Chris Allen - Cible : 2026-10-09
- Prototype du support de gestion - Responsable : Maya Torres - Cible : 2026-10-16
Jalons
- Validation des exigences - Date cible : 2026-09-18
- Premier test de bout en bout - Date cible : 2026-10-12
- Cycle de reporting parallèle - Date cible : 2026-11-02
Dépendances
- Accès API lecture seule à l'ERP.
- Mappage des champs SIRH.
- Approbation des définitions de métriques par la Finance.
Risques / Hypothèses
- Risque : Les limites de débit de l'API ERP peuvent ralentir la première extraction de données.
- Hypothèse : Les définitions des métriques mensuelles existantes resteront inchangées durant le projet pilote.
Accords de travail
- Les modifications de périmètre nécessitent une approbation écrite de Maya et Nina.
- Les questions de définition des données seront consignées dans le canal projet, pas résolues par messages privés.
Rythme de communication
- Point de synchronisation projet de 30 minutes chaque mardi.
- Mise à jour écrite sur le statut chaque vendredi.
Processus décisionnel
Les décisions de processus sont prises par Nina ; les décisions d'implémentation technique sont prises par Chris ; les modifications de périmètre nécessitent l'approbation de Maya et Nina.
Questions en suspens
- La variance des prévisions de trésorerie doit-elle figurer dans la première version ?
Points d'action initiaux
- Rédiger le dictionnaire des métriques - Responsable : Nina Patel - Échéance : 2026-09-11
- Demander l'accès API à l'ERP - Responsable : Chris Allen - Échéance : 2026-09-09
- Créer le registre des risques du projet - Responsable : Maya Torres - Échéance : 2026-09-09
Modèle prêt pour l'IA
TÂCHE
Convertir la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme un point d'action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser « Non spécifié » pour un champ requis manquant.
- Utiliser « Non résolu » pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, points d'action et questions en suspens séparés.
- Préserver les incertitudes et les désaccords lorsqu'ils existent.
FORMAT DE SORTIE
Projet : [ ]
Date de lancement : [ ]
Chef de projet : [ ]
Sponsor : [ ]
Participants : [ ]
Objectif métier
[ ]
Critères de succès
- [ ]
Périmètre - Inclus
- [ ]
Périmètre - Exclu
- [ ]
Parties prenantes
- [ ]
Rôles / Responsabilités
- [ ]
Livrables clés
- [Livrable] - Responsable : [ ] - Cible : [ ]
Jalons
- [Jalon] - Date cible : [ ]
Dépendances
- [ ]
Risques / Hypothèses
- Risque : [ ]
- Hypothèse : [ ]
Accords de travail
- [ ]
Rythme de communication
- [ ]
Processus décisionnel
[ ]
Questions en suspens
- [ ]
Points d'action initiaux
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Ne retourner que le modèle complété.
Convertir la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utiliser uniquement les informations explicitement contenues dans la source.
- Ne pas inventer de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne pas traiter une suggestion comme une décision.
- Ne pas traiter un point de discussion comme un point d'action.
- Ne pas déduire de responsable ou d'échéance.
- Utiliser « Non spécifié » pour un champ requis manquant.
- Utiliser « Non résolu » pour une question soulevée mais sans réponse.
- Garder les discussions, décisions, points d'action et questions en suspens séparés.
- Préserver les incertitudes et les désaccords lorsqu'ils existent.
FORMAT DE SORTIE
Projet : [ ]
Date de lancement : [ ]
Chef de projet : [ ]
Sponsor : [ ]
Participants : [ ]
Objectif métier
[ ]
Critères de succès
- [ ]
Périmètre - Inclus
- [ ]
Périmètre - Exclu
- [ ]
Parties prenantes
- [ ]
Rôles / Responsabilités
- [ ]
Livrables clés
- [Livrable] - Responsable : [ ] - Cible : [ ]
Jalons
- [Jalon] - Date cible : [ ]
Dépendances
- [ ]
Risques / Hypothèses
- Risque : [ ]
- Hypothèse : [ ]
Accords de travail
- [ ]
Rythme de communication
- [ ]
Processus décisionnel
[ ]
Questions en suspens
- [ ]
Points d'action initiaux
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Ne retourner que le modèle complété.
11. Modèle de notes d'entretien
Modèle vierge
Candidat : [ ]
Poste : [ ]
Étape de l'entretien : [ ]
Interviewer : [ ]
Date : [AAAA-MM-JJ]
Compétences évaluées
- [Compétence]
Question 1
Question : [ ]
Réponse / Preuve du candidat : [ ]
Notation de la preuve : [Forte / Mixte / Limitée / Non évaluée]
Notes : [Preuves pertinentes pour le poste uniquement]
Question 2
Question : [ ]
Réponse / Preuve du candidat : [ ]
Notation de la preuve : [Forte / Mixte / Limitée / Non évaluée]
Notes : [ ]
Points forts étayés par des preuves
- [ ]
Préoccupations / Lacunes étayées par des preuves
- [ ]
Questions de suivi
- [ ]
Preuves globales pertinentes pour le poste
[ ]
Recommandation
[Faire avancer / Mettre en attente / Ne pas faire avancer / Non décidé]
Raison : [Preuves liées au poste]
Prochaine étape
[ ]
Poste : [ ]
Étape de l'entretien : [ ]
Interviewer : [ ]
Date : [AAAA-MM-JJ]
Compétences évaluées
- [Compétence]
Question 1
Question : [ ]
Réponse / Preuve du candidat : [ ]
Notation de la preuve : [Forte / Mixte / Limitée / Non évaluée]
Notes : [Preuves pertinentes pour le poste uniquement]
Question 2
Question : [ ]
Réponse / Preuve du candidat : [ ]
Notation de la preuve : [Forte / Mixte / Limitée / Non évaluée]
Notes : [ ]
Points forts étayés par des preuves
- [ ]
Préoccupations / Lacunes étayées par des preuves
- [ ]
Questions de suivi
- [ ]
Preuves globales pertinentes pour le poste
[ ]
Recommandation
[Faire avancer / Mettre en attente / Ne pas faire avancer / Non décidé]
Raison : [Preuves liées au poste]
Prochaine étape
[ ]
Exemple rempli
TÂCHE
Convertissez la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES POUR LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à entreprendre.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez "Non spécifié" pour un champ requis manquant.
- Utilisez "Non résolu" pour une question posée mais restée sans réponse.
- Séparez les discussions, les décisions, les actions et les questions en suspens.
- Préservez les incertitudes et les désaccords lorsqu'ils existent.
RÈGLES POUR LES ACTIONS
- Une action doit commencer par un verbe d'action et décrire un livrable spécifique.
- Si aucune date n'est fixée, indiquez "Non spécifié".
- Si aucun responsable n'est désigné, indiquez "Non spécifié".
- Identifiez les dépendances uniquement si elles sont explicitement mentionnées.
FORMAT DE SORTIE
ID : [ ]
Action : [ ]
Responsable : [ ]
Date d'échéance : [ ]
Priorité : [ ]
Statut : [ ]
Dépendance : [ ]
Réunion source : [ ]
Notes : [ ]
Veuillez retourner uniquement le modèle complété.
Convertissez la transcription ou les notes brutes en utilisant le modèle ci-dessous.
RÈGLES POUR LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, échéances, indicateurs, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à entreprendre.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez "Non spécifié" pour un champ requis manquant.
- Utilisez "Non résolu" pour une question posée mais restée sans réponse.
- Séparez les discussions, les décisions, les actions et les questions en suspens.
- Préservez les incertitudes et les désaccords lorsqu'ils existent.
RÈGLES POUR LES ACTIONS
- Une action doit commencer par un verbe d'action et décrire un livrable spécifique.
- Si aucune date n'est fixée, indiquez "Non spécifié".
- Si aucun responsable n'est désigné, indiquez "Non spécifié".
- Identifiez les dépendances uniquement si elles sont explicitement mentionnées.
FORMAT DE SORTIE
ID : [ ]
Action : [ ]
Responsable : [ ]
Date d'échéance : [ ]
Priorité : [ ]
Statut : [ ]
Dépendance : [ ]
Réunion source : [ ]
Notes : [ ]
Veuillez retourner uniquement le modèle complété.
TÂCHE
Convertissez la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à mener.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez « Non spécifié » pour un champ obligatoire manquant.
- Utilisez « Non résolu » pour une question posée mais restée sans réponse.
- Gardez la discussion, les décisions, les actions à mener et les questions en suspens séparées.
- Préservez l'incertitude et les désaccords lorsqu'ils existent.
RÈGLES POUR LES ACTIONS À MENER (ACTION-ITEM RULES)
- Extrayez une action à mener uniquement lorsque la source indique qu'un travail doit être effectué.
- Rédigez la tâche sous la forme d'un verbe concret + livrable sans en changer le sens.
- N'assignez pas de responsable à partir du contexte à moins que l'intervenant ne s'approprie ou n'accepte explicitement la tâche.
- N'inventez pas de date d'échéance, de priorité ou de statut.
- Ne convertissez pas une question, une idée, une observation ou une responsabilité générale en action à mener.
FORMAT DE SORTIE
ID : [ ]
Action à mener : [Verbe + livrable spécifique]
Responsable : [ ]
Date d'échéance : [ ]
Priorité : [ ]
Statut : [ ]
Dépendance : [ ]
Réunion source : [ ]
Notes : [ ]
Retournez uniquement le modèle complété.
Convertissez la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à mener.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez « Non spécifié » pour un champ obligatoire manquant.
- Utilisez « Non résolu » pour une question posée mais restée sans réponse.
- Gardez la discussion, les décisions, les actions à mener et les questions en suspens séparées.
- Préservez l'incertitude et les désaccords lorsqu'ils existent.
RÈGLES POUR LES ACTIONS À MENER (ACTION-ITEM RULES)
- Extrayez une action à mener uniquement lorsque la source indique qu'un travail doit être effectué.
- Rédigez la tâche sous la forme d'un verbe concret + livrable sans en changer le sens.
- N'assignez pas de responsable à partir du contexte à moins que l'intervenant ne s'approprie ou n'accepte explicitement la tâche.
- N'inventez pas de date d'échéance, de priorité ou de statut.
- Ne convertissez pas une question, une idée, une observation ou une responsabilité générale en action à mener.
FORMAT DE SORTIE
ID : [ ]
Action à mener : [Verbe + livrable spécifique]
Responsable : [ ]
Date d'échéance : [ ]
Priorité : [ ]
Statut : [ ]
Dépendance : [ ]
Réunion source : [ ]
Notes : [ ]
Retournez uniquement le modèle complété.
15. Modèle de notes de réunion de rétrospective
Modèle vierge
Équipe / Projet : [ ]
Période de rétrospective : [Sprint / projet / mois]
Date : [AAAA-MM-JJ]
Facilitateur : [ ]
Participants : [ ]
Objectif / Résultat examiné
[ ]
Ce qui a bien fonctionné
- [ ]
Ce qui n'a pas bien fonctionné
- [ ]
Ce que nous avons appris
- [ ]
Causes profondes identifiées
- [ ]
Commencer
- [Nouveau comportement / processus]
Arrêter
- [Comportement / processus à arrêter]
Continuer
- [Comportement / processus à conserver]
Expériences
- [Expérience] - Mesure de succès : [ ] - Date de révision : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Sujets non résolus
- [ ]
Prochaine date de révision
[ ]
Période de rétrospective : [Sprint / projet / mois]
Date : [AAAA-MM-JJ]
Facilitateur : [ ]
Participants : [ ]
Objectif / Résultat examiné
[ ]
Ce qui a bien fonctionné
- [ ]
Ce qui n'a pas bien fonctionné
- [ ]
Ce que nous avons appris
- [ ]
Causes profondes identifiées
- [ ]
Commencer
- [Nouveau comportement / processus]
Arrêter
- [Comportement / processus à arrêter]
Continuer
- [Comportement / processus à conserver]
Expériences
- [Expérience] - Mesure de succès : [ ] - Date de révision : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Sujets non résolus
- [ ]
Prochaine date de révision
[ ]
Exemple rempli
Équipe / Projet : Équipe Expérience de Paiement
Période de rétrospective : Sprint 18
Date : 2026-09-13
Facilitateur : Jonah Reed
Participants : Jonah Reed, Mei Tan, Alice Brown, Kareem Hassan, Lucy Ford
Objectif / Résultat examiné
Livrer la première version de l'auto-complétion d'adresse et réduire les erreurs d'adresse lors du paiement sans augmenter la latence de la page.
Ce qui a bien fonctionné
- L'auto-complétion d'adresse a été livrée dans les délais.
- L'assurance qualité (QA) a trouvé le problème du clavier mobile avant la mise en production.
- L'ingénierie et le support ont utilisé un document de triage de bugs partagé pendant la semaine de lancement.
Ce qui n'a pas bien fonctionné
- Les noms des événements analytiques ont changé après le début de l'implémentation.
- Deux cas de test pour la gestion des numéros d'appartement manquaient jusqu'à une phase tardive de la QA.
- L'équipe a passé trop de temps lors de la réunion de révision finale à relire des problèmes déjà résolus.
Ce que nous avons appris
- La nomenclature analytique nécessite une approbation avant l'implémentation, et non pendant la QA.
- La révision de lancement doit séparer les problèmes non résolus des problèmes fermés.
Causes profondes identifiées
- Les exigences analytiques ont été traitées comme un détail d'implémentation plutôt que comme une dépendance de lancement.
- La liste de contrôle QA ne couvrait pas explicitement les champs d'adresse secondaires.
Commencer
- Exiger l'approbation du nom de l'événement analytique avant le début de l'implémentation front-end.
- Utiliser une vue de révision de lancement qui affiche uniquement les problèmes ouverts ou récemment modifiés.
Arrêter
- La réouverture de problèmes de lancement résolus dans la révision principale, sauf en présence de nouvelles preuves.
Continuer
- Le triage de bugs partagé entre l'Ingénierie et le Support pendant la semaine de lancement.
Expériences
- Ajouter un point de validation analytique à la planification du Sprint 19 - Mesure de succès : Aucun changement de nom d'événement après le début de l'implémentation - Date de révision : 2026-09-27
Actions à mener
- Ajouter la validation analytique à la liste de contrôle de lancement - Responsable : Mei Tan - Échéance : 2026-09-16
- Ajouter les cas de champs d'adresse secondaires au modèle QA - Responsable : Alice Brown - Échéance : 2026-09-16
- Créer une vue de lancement avec uniquement les problèmes ouverts - Responsable : Kareem Hassan - Échéance : 2026-09-18
Sujets non résolus
- Déterminer si l'équipe a besoin d'une réunion de révision analytique dédiée avant le lancement.
Prochaine date de révision
2026-09-27
Période de rétrospective : Sprint 18
Date : 2026-09-13
Facilitateur : Jonah Reed
Participants : Jonah Reed, Mei Tan, Alice Brown, Kareem Hassan, Lucy Ford
Objectif / Résultat examiné
Livrer la première version de l'auto-complétion d'adresse et réduire les erreurs d'adresse lors du paiement sans augmenter la latence de la page.
Ce qui a bien fonctionné
- L'auto-complétion d'adresse a été livrée dans les délais.
- L'assurance qualité (QA) a trouvé le problème du clavier mobile avant la mise en production.
- L'ingénierie et le support ont utilisé un document de triage de bugs partagé pendant la semaine de lancement.
Ce qui n'a pas bien fonctionné
- Les noms des événements analytiques ont changé après le début de l'implémentation.
- Deux cas de test pour la gestion des numéros d'appartement manquaient jusqu'à une phase tardive de la QA.
- L'équipe a passé trop de temps lors de la réunion de révision finale à relire des problèmes déjà résolus.
Ce que nous avons appris
- La nomenclature analytique nécessite une approbation avant l'implémentation, et non pendant la QA.
- La révision de lancement doit séparer les problèmes non résolus des problèmes fermés.
Causes profondes identifiées
- Les exigences analytiques ont été traitées comme un détail d'implémentation plutôt que comme une dépendance de lancement.
- La liste de contrôle QA ne couvrait pas explicitement les champs d'adresse secondaires.
Commencer
- Exiger l'approbation du nom de l'événement analytique avant le début de l'implémentation front-end.
- Utiliser une vue de révision de lancement qui affiche uniquement les problèmes ouverts ou récemment modifiés.
Arrêter
- La réouverture de problèmes de lancement résolus dans la révision principale, sauf en présence de nouvelles preuves.
Continuer
- Le triage de bugs partagé entre l'Ingénierie et le Support pendant la semaine de lancement.
Expériences
- Ajouter un point de validation analytique à la planification du Sprint 19 - Mesure de succès : Aucun changement de nom d'événement après le début de l'implémentation - Date de révision : 2026-09-27
Actions à mener
- Ajouter la validation analytique à la liste de contrôle de lancement - Responsable : Mei Tan - Échéance : 2026-09-16
- Ajouter les cas de champs d'adresse secondaires au modèle QA - Responsable : Alice Brown - Échéance : 2026-09-16
- Créer une vue de lancement avec uniquement les problèmes ouverts - Responsable : Kareem Hassan - Échéance : 2026-09-18
Sujets non résolus
- Déterminer si l'équipe a besoin d'une réunion de révision analytique dédiée avant le lancement.
Prochaine date de révision
2026-09-27
Modèle prêt pour l'IA
TÂCHE
Convertissez la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à mener.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez « Non spécifié » pour un champ obligatoire manquant.
- Utilisez « Non résolu » pour une question posée mais restée sans réponse.
- Gardez la discussion, les décisions, les actions à mener et les questions en suspens séparées.
- Préservez l'incertitude et les désaccords lorsqu'ils existent.
RÈGLES DE RÉTROSPECTIVE
- Gardez les observations, les leçons inférées et les causes profondes confirmées séparées.
- Enregistrez une cause profonde uniquement lorsque les participants l'identifient ou s'accordent explicitement dessus comme telle.
- Ne transformez pas une critique de processus en critique de personne, sauf si la source le présente explicitement ainsi.
FORMAT DE SORTIE
Équipe / Projet : [ ]
Période de rétrospective : [ ]
Date : [ ]
Facilitateur : [ ]
Participants : [ ]
Objectif / Résultat examiné
[ ]
Ce qui a bien fonctionné
- [ ]
Ce qui n'a pas bien fonctionné
- [ ]
Ce que nous avons appris
- [ ]
Causes profondes identifiées
- [ ]
Commencer
- [ ]
Arrêter
- [ ]
Continuer
- [ ]
Expériences
- [Expérience] - Mesure de succès : [ ] - Date de révision : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Sujets non résolus
- [ ]
Prochaine date de révision
[ ]
Retournez uniquement le modèle complété.
Convertissez la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à mener.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez « Non spécifié » pour un champ obligatoire manquant.
- Utilisez « Non résolu » pour une question posée mais restée sans réponse.
- Gardez la discussion, les décisions, les actions à mener et les questions en suspens séparées.
- Préservez l'incertitude et les désaccords lorsqu'ils existent.
RÈGLES DE RÉTROSPECTIVE
- Gardez les observations, les leçons inférées et les causes profondes confirmées séparées.
- Enregistrez une cause profonde uniquement lorsque les participants l'identifient ou s'accordent explicitement dessus comme telle.
- Ne transformez pas une critique de processus en critique de personne, sauf si la source le présente explicitement ainsi.
FORMAT DE SORTIE
Équipe / Projet : [ ]
Période de rétrospective : [ ]
Date : [ ]
Facilitateur : [ ]
Participants : [ ]
Objectif / Résultat examiné
[ ]
Ce qui a bien fonctionné
- [ ]
Ce qui n'a pas bien fonctionné
- [ ]
Ce que nous avons appris
- [ ]
Causes profondes identifiées
- [ ]
Commencer
- [ ]
Arrêter
- [ ]
Continuer
- [ ]
Expériences
- [Expérience] - Mesure de succès : [ ] - Date de révision : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Sujets non résolus
- [ ]
Prochaine date de révision
[ ]
Retournez uniquement le modèle complété.
16. Modèle de notes de remue-méninges / atelier
Modèle vierge
Session : [ ]
Date : [AAAA-MM-JJ]
Facilitateur : [ ]
Participants : [ ]
Problème / Sujet : [ ]
Contraintes : [ ]
Idées
1. [Idée]
2. [Idée]
3. [Idée]
Thèmes / Regroupements
- [Thème] : [Idées associées]
Questions soulevées
- [ ]
Votes / Scores
- [Idée] - [Votes / score / critères]
Idées présélectionnées
- [ ]
Direction choisie
[Décision ou Non résolu]
Raisons
- [ ]
Idées non retenues / différées
- [Idée] - Raison si précisée : [ ]
Prochaines expériences
- [Expérience] - Responsable : [ ] - Échéance : [ ] - Mesure de succès : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Date : [AAAA-MM-JJ]
Facilitateur : [ ]
Participants : [ ]
Problème / Sujet : [ ]
Contraintes : [ ]
Idées
1. [Idée]
2. [Idée]
3. [Idée]
Thèmes / Regroupements
- [Thème] : [Idées associées]
Questions soulevées
- [ ]
Votes / Scores
- [Idée] - [Votes / score / critères]
Idées présélectionnées
- [ ]
Direction choisie
[Décision ou Non résolu]
Raisons
- [ ]
Idées non retenues / différées
- [Idée] - Raison si précisée : [ ]
Prochaines expériences
- [Expérience] - Responsable : [ ] - Échéance : [ ] - Mesure de succès : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Exemple rempli
Session : Réduire le temps de configuration pour les nouveaux clients
Date : 2026-09-06
Facilitateur : Morgan Hale
Participants : Morgan Hale, Priya Singh, Evan Ross, Jenna Clark, Luis Moreno
Problème / Sujet : Comment l'équipe peut-elle réduire le temps moyen entre la signature du contrat et la première configuration réussie du client ?
Contraintes : Aucun effectif d'implémentation supplémentaire au T4 ; la revue de sécurité ne peut pas être supprimée.
Idées
1. Pré-remplir les formulaires d'implémentation à partir des données d'opportunité CRM.
2. Remplacer l'appel de lancement de 60 minutes par un appel de configuration structuré de 30 minutes.
3. Créer une liste de contrôle de préparation à l'implémentation pour les Ventes avant le transfert.
4. Créer un validateur de format de données en libre-service.
5. Proposer des heures de permanence de configuration de groupe deux fois par semaine pour les petits comptes.
6. Assigner un spécialiste d'implémentation par secteur d'activité.
Thèmes / Regroupements
- Meilleures données de transfert : Pré-remplissage CRM, liste de contrôle de préparation des ventes.
- Validation plus rapide : Validateur de données en libre-service.
- Refonte des réunions : Appel de configuration plus court, heures de permanence de groupe.
- Spécialisation : Assignation de spécialiste par secteur d'activité.
Questions soulevées
- À quelle fréquence les données CRM manquantes sont-elles réellement responsables des retards de configuration ?
- Les heures de permanence de groupe fonctionneraient-elles pour les clients ayant des configurations sensibles en matière de sécurité ?
Votes / Scores
- Liste de contrôle de préparation des ventes - 5 votes
- Validateur de données en libre-service - 5 votes
- Pré-remplissage CRM - 4 votes
- Appel de configuration de 30 minutes - 2 votes
- Heures de permanence de groupe - 2 votes
- Assignation de spécialiste par secteur - 1 vote
Idées présélectionnées
- Liste de contrôle de préparation des ventes.
- Validateur de données en libre-service.
- Pré-remplissage CRM.
Direction choisie
Mener deux expériences : une liste de contrôle de préparation des ventes et un prototype de validateur de données léger. Le pré-remplissage CRM reste une idée de suivi en attente d'une analyse de la qualité des données.
Raisons
- La liste de contrôle de préparation peut être testée immédiatement sans travail d'ingénierie.
- Le validateur cible une source répétée de retard d'implémentation et peut être prototypé avant le développement complet.
Idées non retenues / différées
- Pré-remplissage CRM - Raison si précisée : Nécessité de mesurer d'abord l'exhaustivité des données sources.
- Appel de configuration de 30 minutes - Raison si précisée : L'équipe souhaite la preuve que la durée du lancement cause un retard.
- Heures de permanence de groupe - Raison si précisée : Les comptes sensibles sur le plan de la sécurité peuvent nécessiter des sessions privées.
- Assignation de spécialiste par secteur - Raison si précisée : Entre en conflit avec le modèle de capacité actuel.
Prochaines expériences
- Pilote de liste de contrôle de préparation des ventes - Responsable : Jenna Clark - Échéance : 2026-09-14 - Mesure de succès : Pourcentage de transferts pilotes arrivant avec toutes les informations requises
- Prototype de validateur de données - Responsable : Luis Moreno - Échéance : 2026-09-21 - Mesure de succès : Détecter les cinq erreurs de format d'importation les plus courantes avant la révision d'implémentation
Actions à mener
- Extraire les raisons des retards de transfert sur trois mois - Responsable : Evan Ross - Échéance : 2026-09-11
- Rédiger la liste de contrôle de préparation - Responsable : Jenna Clark - Échéance : 2026-09-09
Date : 2026-09-06
Facilitateur : Morgan Hale
Participants : Morgan Hale, Priya Singh, Evan Ross, Jenna Clark, Luis Moreno
Problème / Sujet : Comment l'équipe peut-elle réduire le temps moyen entre la signature du contrat et la première configuration réussie du client ?
Contraintes : Aucun effectif d'implémentation supplémentaire au T4 ; la revue de sécurité ne peut pas être supprimée.
Idées
1. Pré-remplir les formulaires d'implémentation à partir des données d'opportunité CRM.
2. Remplacer l'appel de lancement de 60 minutes par un appel de configuration structuré de 30 minutes.
3. Créer une liste de contrôle de préparation à l'implémentation pour les Ventes avant le transfert.
4. Créer un validateur de format de données en libre-service.
5. Proposer des heures de permanence de configuration de groupe deux fois par semaine pour les petits comptes.
6. Assigner un spécialiste d'implémentation par secteur d'activité.
Thèmes / Regroupements
- Meilleures données de transfert : Pré-remplissage CRM, liste de contrôle de préparation des ventes.
- Validation plus rapide : Validateur de données en libre-service.
- Refonte des réunions : Appel de configuration plus court, heures de permanence de groupe.
- Spécialisation : Assignation de spécialiste par secteur d'activité.
Questions soulevées
- À quelle fréquence les données CRM manquantes sont-elles réellement responsables des retards de configuration ?
- Les heures de permanence de groupe fonctionneraient-elles pour les clients ayant des configurations sensibles en matière de sécurité ?
Votes / Scores
- Liste de contrôle de préparation des ventes - 5 votes
- Validateur de données en libre-service - 5 votes
- Pré-remplissage CRM - 4 votes
- Appel de configuration de 30 minutes - 2 votes
- Heures de permanence de groupe - 2 votes
- Assignation de spécialiste par secteur - 1 vote
Idées présélectionnées
- Liste de contrôle de préparation des ventes.
- Validateur de données en libre-service.
- Pré-remplissage CRM.
Direction choisie
Mener deux expériences : une liste de contrôle de préparation des ventes et un prototype de validateur de données léger. Le pré-remplissage CRM reste une idée de suivi en attente d'une analyse de la qualité des données.
Raisons
- La liste de contrôle de préparation peut être testée immédiatement sans travail d'ingénierie.
- Le validateur cible une source répétée de retard d'implémentation et peut être prototypé avant le développement complet.
Idées non retenues / différées
- Pré-remplissage CRM - Raison si précisée : Nécessité de mesurer d'abord l'exhaustivité des données sources.
- Appel de configuration de 30 minutes - Raison si précisée : L'équipe souhaite la preuve que la durée du lancement cause un retard.
- Heures de permanence de groupe - Raison si précisée : Les comptes sensibles sur le plan de la sécurité peuvent nécessiter des sessions privées.
- Assignation de spécialiste par secteur - Raison si précisée : Entre en conflit avec le modèle de capacité actuel.
Prochaines expériences
- Pilote de liste de contrôle de préparation des ventes - Responsable : Jenna Clark - Échéance : 2026-09-14 - Mesure de succès : Pourcentage de transferts pilotes arrivant avec toutes les informations requises
- Prototype de validateur de données - Responsable : Luis Moreno - Échéance : 2026-09-21 - Mesure de succès : Détecter les cinq erreurs de format d'importation les plus courantes avant la révision d'implémentation
Actions à mener
- Extraire les raisons des retards de transfert sur trois mois - Responsable : Evan Ross - Échéance : 2026-09-11
- Rédiger la liste de contrôle de préparation - Responsable : Jenna Clark - Échéance : 2026-09-09
Modèle prêt pour l'IA
TÂCHE
Convertissez la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à mener.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez « Non spécifié » pour un champ obligatoire manquant.
- Utilisez « Non résolu » pour une question posée mais restée sans réponse.
- Gardez la discussion, les décisions, les actions à mener et les questions en suspens séparées.
- Préservez l'incertitude et les désaccords lorsqu'ils existent.
RÈGLES DE REMUE-MÉNINGES
- Gardez les idées générées séparées des idées sélectionnées.
- Ne traitez pas un vote, un score élevé, une réaction positive ou une suggestion comme une décision approuvée à moins que la source ne dise qu'elle a été sélectionnée.
- Préservez les idées différées au lieu de les supprimer.
- N'inventez pas de raisons pour le rejet ou la sélection.
FORMAT DE SORTIE
Session : [ ]
Date : [ ]
Facilitateur : [ ]
Participants : [ ]
Problème / Sujet : [ ]
Contraintes : [ ]
Idées
1. [ ]
Thèmes / Regroupements
- [Thème] : [ ]
Questions soulevées
- [ ]
Votes / Scores
- [Idée] - [ ]
Idées présélectionnées
- [ ]
Direction choisie
[ ]
Raisons
- [ ]
Idées non retenues / différées
- [Idée] - Raison si précisée : [ ]
Prochaines expériences
- [Expérience] - Responsable : [ ] - Échéance : [ ] - Mesure de succès : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Retournez uniquement le modèle complété.
Convertissez la transcription ou les notes brutes dans le modèle ci-dessous.
RÈGLES DE LA SOURCE
- Utilisez uniquement les informations explicitement contenues dans la source.
- N'inventez pas de noms, dates, responsables, décisions, engagements, délais, métriques, raisons, votes ou résultats.
- Ne traitez pas une suggestion comme une décision.
- Ne traitez pas un point de discussion comme une action à mener.
- N'inférez pas de responsable ou de date d'échéance.
- Utilisez « Non spécifié » pour un champ obligatoire manquant.
- Utilisez « Non résolu » pour une question posée mais restée sans réponse.
- Gardez la discussion, les décisions, les actions à mener et les questions en suspens séparées.
- Préservez l'incertitude et les désaccords lorsqu'ils existent.
RÈGLES DE REMUE-MÉNINGES
- Gardez les idées générées séparées des idées sélectionnées.
- Ne traitez pas un vote, un score élevé, une réaction positive ou une suggestion comme une décision approuvée à moins que la source ne dise qu'elle a été sélectionnée.
- Préservez les idées différées au lieu de les supprimer.
- N'inventez pas de raisons pour le rejet ou la sélection.
FORMAT DE SORTIE
Session : [ ]
Date : [ ]
Facilitateur : [ ]
Participants : [ ]
Problème / Sujet : [ ]
Contraintes : [ ]
Idées
1. [ ]
Thèmes / Regroupements
- [Thème] : [ ]
Questions soulevées
- [ ]
Votes / Scores
- [Idée] - [ ]
Idées présélectionnées
- [ ]
Direction choisie
[ ]
Raisons
- [ ]
Idées non retenues / différées
- [Idée] - Raison si précisée : [ ]
Prochaines expériences
- [Expérience] - Responsable : [ ] - Échéance : [ ] - Mesure de succès : [ ]
Actions à mener
- [Tâche] - Responsable : [ ] - Échéance : [ ]
Retournez uniquement le modèle complété.
0 commentaire