Remplacer Jira par Notion pour une équipe produit de cinq personnes, c’est possible — et je l’ai fait. Si vous vous demandez comment structurer vos données, garder une roadmap claire, gérer les sprints et conserver la traçabilité sans perdre en rigueur, cet article partage mon retour d’expérience pratique : modèles, bases de données, vues, automatisations et limites à connaître.
Pourquoi j’ai choisi Notion plutôt que Jira
Jira est puissant, mais pour une petite équipe de produit nous n’avions pas besoin de toute la complexité. Notion nous a offert :
- une interface unifiée (doc + gestion de tâches) qui facilite la communication;
- une plus grande flexibilité pour designer des workflows sur-mesure;
- des coûts plus maîtrisés et une courbe d’adoption rapide pour des profils non techniques;
- la possibilité d’intégrer roadmaps, spécifications et tickets techniques dans le même espace.
Principes que j’ai posés avant de commencer
Avant de construire quoi que ce soit, j’ai défini des règles simples pour éviter le chaos :
- Une source de vérité : une base de données principale pour les issues (tickets) qui alimente toutes les vues;
- Convention de nommage : préfixes pour les types de ticket (BUG-, FEAT-, TECH-), et format des pages;
- Simplicité des statuts : réduire à 6 statuts (Backlog, À faire, En cours, En revue, Bloqué, Fini);
- Responsabilités claires : propriétaire du ticket, QA, epic/link éventuel;
- Documentation liée : chaque ticket peut contenir brief, maquette Figma, logs, checklist de QA.
Architecture Notion que j’ai construite
Voici les éléments principaux que j’ai créés dans l’espace d’équipe :
- Base de données "Issues" (la source de vérité).
- Base de données "Epics / Roadmap" liée à Issues.
- Board "Sprint" (vue filtrée de Issues pour le sprint en cours).
- Vue "Backlog" (priorisée, avec champs de score).
- Page "Documentation produit" (spécifications, guidelines, liens Figma).
- Dashboard d’équipe (vue synthétique : vélocité, tickets bloqués, sprint en cours).
Détail de la base de données "Issues"
La colonne la plus importante, c’est la structure des propriétés. Je vous donne la maquette de champs que j’utilise :
| Champ | Type | Usage |
|---|---|---|
| Title | Titre | Résumé concis |
| ID | Texte / Formula | Ex. "FEAT-123" (généré ou manuel) |
| Type | Sélection | Feature / Bug / Tech / Chore |
| Status | Sélection | Backlog, À faire, En cours, En revue, Bloqué, Fini |
| Priority | Sélection | Low / Medium / High / Critical |
| Assignee | Person | Responsable |
| Estimate | Number | Story points ou jours |
| Epic | Relation | Lien vers la base Epics / Roadmap |
| Sprint | Texte / Sélection | Nom du sprint ou numéro |
| Blocked by | Relation | Lien vers d’autres issues |
| Created / Updated | Date | Historique |
| Checklist QA | Checkbox / To-do | Contrôles à valider pour fermer |
J’utilise la propriété Relation pour lier Issues et Epics afin de naviguer facilement entre stratégie (roadmap) et exécution (tickets).
Vues essentielles et leur utilité
Des vues adaptées permettent à chaque membre de l’équipe d’obtenir ce dont il a besoin en un coup d’œil :
- Board sprint : vue Kanban filtrée sur le sprint actif, organisée par Status. C’est notre tableau de travail quotidien.
- Backlog priorisé : vue table triée par score/priorité, avec possibilité de modifier l’estimation.
- Roadmap : calendrier ou timeline des Epics, avec progression liée aux Issues.
- Mes tickets : filtre "Assignee = moi" pour focuser.
- Tickets bloqués : filtre "Status = Bloqué" et affichage des relations Bloqué par.
- Archive : filtre sur Status = Fini pour masquer le bruit.
Workflow de sprint que j’applique
Voici comment un ticket passe de l’idée à la production dans notre Notion :
- Création dans Backlog avec brief et estimation initiale.
- Grooming hebdomadaire : priorisation et découpage; assignation d’un estimateur.
- Ajout au Sprint lors de la planification (mouvement vers la vue Sprint + mise du champ Sprint).
- Travail en cours (Assignee avance, checklist QA remplie).
- Revue / QA : review demandé, commentaire et checklist complétée.
- Déploiement et basculement en Fini + notations / rétrospective.
Automatisations et intégrations
Notion manque de certaines automatisations natives par rapport à Jira, mais on compense :
- Zapier / Make (Integromat) : pour créer des notifications Slack quand un ticket devient Bloqué ou Fini.
- GitHub / GitLab : lier PRs à un ticket Notion via URL, ou créer des issues Notion depuis un commit via API.
- Notion API : scripts maison pour synchroniser estimates ou calculer vélocité automatiquement.
- Figma : embed direct dans les pages ticket pour centraliser spécifications et maquettes.
Templates de ticket
Pour conserver la qualité, j’ai créé des templates (templates de page) pour :
- Feature : objectifs, critères d’acceptance, UX, impact métriques, checklist de QA.
- Bug : steps to reproduce, logs, impact, sélection de priorités.
- Tech task : contexte technique, dépendances, plan de migration.
Mesures de performance et suivi (vélocité)
Pour remplacer les rapports Jira, j’ai mis en place des vues et des formules Notion pour suivre la vélocité :
- Formules pour sommer les Estimates des tickets Fini sur une période donnée.
- Tableau "Sprint Summary" affichant nombre de tickets, sum estimates, tickets bloqués.
- Graphiques simples exportés via CSV et visualisés dans Google Sheets ou Notion Charts (intégration tierce) si nécessaire.
Gestion des droits et bonnes pratiques de collaboration
Notion est plus permissif; voici comment j’ai sécurisé l’espace :
- Pages publiques limitées ; workspace d’équipe pour tout le reste.
- Permissions par page : éditeurs pour l’équipe produit, lecteurs pour stakeholders.
- Règles d’édition : ne pas modifier les propriétés système (ID, Epic) sans coordination.
- Rituels : standup quotidien sur le board Sprint et revue hebdo du backlog.
Les limites à connaître
Notion n’est pas Jira et présente quelques limites :
- Manque de features avancées (workflows complexes, reporting profond, permissions granulaires par ticket).
- Historique d’audit moins riche que Jira ; la traçabilité avancée est limitée.
- Performances : les bases très volumineuses peuvent devenir lentes — pour une petite équipe, ça passe, mais attention à l’échelle.
- Automatisations natives moins nombreuses : prévoir des outils externes si vous voulez synchronisations poussées.
Conseils pratiques pour une migration depuis Jira
Si vous migrez de Jira vers Notion, procédez en étapes :
- Exporter les tickets Jira (CSV).
- Nettoyer et mapper les champs (statuts -> nos statuts simplifiés, types, assignees).
- Importer par lot dans la base Issues (Notion supporte l’import CSV avec mapping).
- Vérifier relations (Epics) manuellement et corriger les liens.
- Lancer un pilote de 2 sprints et ajuster templates / vues selon les retours.
Remplacer complètement Jira par Notion est un choix pragmatique pour une équipe produit de cinq personnes : vous gagnez en souplesse, en documentation centralisée et en adoption rapide. En suivant les règles de structuration, en automatisant les points critiques et en acceptant certaines limites, Notion devient un outil de management produit crédible et agréable à utiliser au quotidien.
