La Définition du Fini

Fabrice Aimetti — Mon, 10 Aug 2026 11:53:31 GMT

Fabrice Aimetti : Page créée avec « Category: Portail ScrumMaster Catégorie:DoD Auteur : Derek Huether Source : [https://www.liminalarc.co/2017/02/definition-of-done/ Definition of Done] Date : 08/02/2017 ---- Traducteur : Fabrice Aimetti Date : 10/08/2026 ---- Traduction : == Est-ce fini, est-ce vraiment fini, ou est-ce carrément fini ? == Si vous travaillez dans le domaine du développement d’applications, vous vous êtes déjà posé cette question. Al... »

Un conseil pour une équipe avec un nouveau chef qui ne connaît pas le Lean et qui souhaite plutôt nous faire passer à l'Agilité ?

Fabrice Aimetti — Fri, 31 Jul 2026 09:21:56 GMT

Fabrice Aimetti :

[[Catégorie: Portail Lean]]
[[Category: Gemba]]
[[Category: Jidoka]]
[[Catégorie: Michael Ballé]]
Auteur : Michael Ballé 
Source : [https://www.lean.org/balle/DisplayObject.cfm?o=4983 Any advice for a team with a new boss who doesn’t know lean but wants us to switch to agile instead?] 
Date : 08/07/2019 
----
Traducteur : Fabrice Aimetti 
Date : 28/07/2019 
----
Traduction : 
 
'''Cher coach Gemba,''' 
 
'''Nous avons un nouveau chef qui ne connaît pas le Lean et qui demande à notre équipe Lean de passer à "l'Agilité". Un conseil ?''' 
 
Dites à votre chef que vous faites déjà de l'Agilité - il n'y a pas vraiment de différence entre l'Agilité et le Lean. Le chef n'a pas toujours raison, mais le chef est toujours le chef. Une règle d'or de la psychologie est que les gens réduisent les problèmes complexes jusqu'à la partie qu'ils pensent pouvoir résoudre. La grande clairvoyance du Lean c'est de pouvoir faire des hypothèses sur la façon dont un site de travail fonctionne (et va fonctionner) en fonction des problèmes que le chef prend en charge, de la façon dont il les définit et de la façon dont il les résout (avec les gens ou en imposant aux gens sa façon de faire), et le type de solutions qu'il préfère. 
 
Si vous avez utilisé des techniques Lean Kanban pour établir un flux d'informations plus rapproché entre les concepteurs et les développeurs, alors l'Agilité sera probablement un retour en arrière.
 La vraie question est la suivante : que perdez-vous en abandonnant le Lean et en adoptant l'Agilité ? Tout dépend du type de Lean que vous pratiquez. Dans certains cas, vous pourriez passer à l'étape supérieure. 
 
J'étais sur la gemba récemment dans un département informatique et j'ai eu exactement cette discussion avec le manager Agile. Ils ne veulent pas entendre parler de l'approche Lean pour leur entreprise parce qu'ils la trouvent trop rigide - ils ne pensent pas que dans leur environnement complexe et en évolution rapide, les standards et les processus standards s'appliquent à eux - et je ne suis pas nécessairement en désaccord avec eux. 
 
D'un autre côté, ils ont admis qu'ils avaient de longs ''lead times'', un énorme backlog et beaucoup de ''rework'', même s'ils pratiquaient l'Agilité depuis des années, ce qui signifie essentiellement cela :
* Ils définissent le travail à travers des stories : ils définissent les fonctionnalités avec des "personas" utilisateurs, spécifiant ce que cet "utilisateur" aimerait faire pour obtenir cela et le décomposant en petits morceaux de travail - des epics et des stories - à développer.
* Ils travaillent en petits lots : ils livrent le travail une fois par jour ou une fois toutes les deux semaines et essaient de tester le code avant la livraison.
* Ils travaillent en équipe : tous les matins, ils mènent une mêlée quotidienne pour discuter du travail à faire et des problèmes qu'ils rencontrent.
 
Et ça marche ! Ils livrent. 
 
Qu'est-ce que le Lean leur apporterait ? 
 
== Différents points de départ ==
La partie difficile. L'Agilité est une victoire incontestable par rapport à la planification d'un système entier et à des mois de développement de portions de code à livrer et à faire fonctionner ensemble à la fin. Mais il reste un système qui organise l'équipe et s'arrête à l'individu développeur et donc - le code. Il y a beaucoup de techniques Agile pour examiner la qualité du code, mais jusqu'à présent, je ne les ai jamais vu si bien appliquées. 
 
À l'autre bout du spectre, les clients des équipes Agile sont beaucoup plus heureux parce qu'ils voient la livraison continue des fonctionnalités, mais il n'est pas clair que le produit résultant soit mieux apprécié ou plus utilisé qu'avec la méthode traditionnelle en V. 
 
L'un des problèmes clés de la pensée Agile est que - d'après ce que j'ai vu - elle est fortement orientée fonctionnalités. Le logiciel qui en résulte a tendance à être chargé de fonctionnalités, aucune d'entre elles n'est très utile et ne fonctionne pas nécessairement très bien pour les utilisateurs sur les quelques fonctionnalités clés dont ils ont vraiment besoin, sur des problèmes plus profonds tels que la vitesse, les bogues et les problèmes, et la sécurité des données. 
 
Le Lean commence à un point différent - non pas avec l'équipe, mais avec le développeur et le product owner ou l'architecte (en termes lean, l'ingénieur en chef). 
 
Avec l'Agilité, l'équipe regarde le tableau d'affichage des tickets, en prend un du backlog de stories et le pousse dans les files d'attente "à faire", "en cours", "en revue", "fini" - beaucoup de variations sur ces en-têtes, mais ils font principalement la même chose. 
 
Quand vous regardez le tableau, certains tickets avancent, d'autres s'attardent. L'équipe ré-ordonnance les tickets en fonction de ce qui a été réalisé et de ce qui a été bloqué. La plupart du temps, le manager a une vois prépondérante et c'est lui qui décide en dernier ressort de ce qui doit être fait et de ce qui sera reporté. 
 
Le Lean commence par le développeur. Le flux de tickets doit se faire sur le poste de travail : voici ce sur quoi vous devez travailler ensuite, et ensuite, et ensuite c'est tout - comme un cuisinier dans une cuisine recevant les commandes des tables du restaurant. 
 
L'intérêt d'amener la file d'attente jusqu'au poste de travail est de rendre la personne autonome : elle n'a pas besoin d'une équipe ou d'un chef pour savoir quoi faire. Elle peut travailler seule ET appeler à l'aide si elle rencontre un problème. 
 
La raison pour laquelle le travail s'accumule sur les bureaux des gens, c'est que lorsqu'ils rencontrent une difficulté, ils mettent de côté le travail pénible et commencent quelque chose d'autre - ce qui a du sens. S'ils se heurtent à un deuxième problème, ils mettent de côté ce deuxième travail et ainsi de suite. Nous le faisons tous. Certaines difficultés se résolvent facilement - obtenir une information manquante de quelqu'un. D'autres s'attarderont et s'aggraveront parce qu'ils sont la partie cachée de l'iceberg de problèmes plus profonds. 
 

== Construire la Qualité intrinsèque ==
Le Lean ne fonctionne pas sans Andon - la ligne de management est là pour être une chaîne d'aide. Lorsqu'une personne rencontre un problème, au lieu de le mettre de côté et de travailler sur autre chose, le management se présente et résout le problème, plutôt que de passer à une autre tâche. Ce n'est jamais facile, mais c'est ainsi que nous découvrons les vrais problèmes dès le début, et les résolvons. 
 
Cette chose simple mais difficile est la clé de la qualité intrinsèque : en fin de compte, le produit sera beaucoup plus robuste que si nous continuons à travailler, si nous poussons tous les problèmes sur la voie et si nous espérons que l'intégration nous permettra de les résoudre tous ensemble - voyez ce qui se passe lorsque les managers essaient cela avec la conception des avions. Aïe. 
 
Et nous arrivons ici à un malentendu majeur au sujet du Lean. Le Andon ne consiste pas seulement à aider les développeurs et à les former à faire des choses quand nous le pouvons. Le Andon vise à comprendre pourquoi le développeur a le problème en premier lieu et où nous nous sommes trompés dans l'instruction de travail. 
 
L'autre partie de l'équation est l'architecte (en termes Agile, l'ingénieur en chef en Lean), la personne qui garde une vision globale de : 
 
<center>Bénéfices pour les clients : fonctionnalités -- technologies -- intégration dans l'ensemble du système -- coût total.</center>
 
Quelqu'un doit concevoir le travail. En Lean, l'ingénierie conçoit l'ouvrage dans les moindres détails et utilise ensuite les problèmes de production pour affiner cette conception. Dans l'Agilité, le travail est conçu avec un coup de pinceau plus large et les développeurs trouvent un moyen de le faire fonctionner. 
 
Dans le cadre d'une pensée Lean, nous mettons l'accent sur les nouvelles fonctionnalités que nous apportons au marché et nous nous assurons qu'elles ne nuisent pas à la performance globale du produit et qu'elles sont solidement conçues avec des standards afin que les équipes de production savent quoi faire. Les fonctionnalités innovantes ou l'utilisation d'une technologie innovante sont utilisées avec parcimonie, dans des projets qui font l'objet d'une forte surveillance. 
 
Le développement Agile a tendance à être beaucoup moins strict avec la production d'un code qui fasse le travail, et les architectes ont tendance à voir des progrès en termes d'ajout de fonctionnalités pour satisfaire davantage les besoins des utilisateurs (avertissement : généralisation large ici, deux architectes n'ont pas le même point de vue sur cette question). C'est une différence fondamentale qui explique une grande partie des discussions Agile/Lean. 
 
[[Fichier:Balle agile1.png|300px|link=]] 
 
En Lean, le mécanisme de feedback à la conception n'est pas la réaction de l'utilisateur face au produit complet une fois qu'il est mis à l'épreuve sur le terrain, mais le processus même du ''stop-and-fix'' / arrêt-répare (si les concepteurs sont réellement intéressés). 
 
En Lean, la production elle-même est la méthode de test de la conception. 
 
[[Fichier:Balle agile2.png|300px|link=]] 
 
Les ateliers et formations ''kaizen'' sont vraiment intéressants en Lean lorsque nous abordons des problèmes de conception profonds qui peuvent ensuite être expliqués aux ingénieurs. Les explications ne seront utiles que si le concepteur a une connaissance approfondie des bénéfices pour le client, des fonctionnalités et de la technologie nécessaire pour les livrer avec qualité et facilité, à un coût raisonnable. Pas facile. 
 
En fin de compte, les techniques Lean ont pour but d'aider les gens à voir au-delà des frontières de leur travail fonctionnel - l'objectif est une meilleure collaboration tout au long de la chaîne et la suppression des coûts - gaspillage - des lacunes dans la coopération (rien de plus inutile qu'un produit non utilisé par les utilisateurs). 
 
Malheureusement, de nombreux programmes Lean sont exclusivement axés sur l'amélioration de la productivité de chaque équipe et passent complètement à côté de l'objectif global de "vendre un produit, en fabriquer un - pour s'assurer que vous continuez à en vendre un". 
 
Pour répondre à votre question, cela dépend vraiment du type de programme Lean que vous avez exécuté. Si l'accent a été mis sur le travail standardisé et les processus standardisés, comme certains essaient de le faire, l'Agilité sera un pas en avant. Cela détendra l'atmosphère et vous empêchera de forcer les clients et le personnel avec vos processus arbitraires. D'un autre côté, si vous avez utilisé des techniques Lean Kanban pour établir un flux d'informations plus rapproché entre les concepteurs et les développeurs, alors l'Agilité sera probablement un retour en arrière, permettant aux ''middle managers'' de reprendre le contrôle du qui-fait-quoi et de ne plus examiner le code des développeurs. 
 
Les questions clés sont les suivantes : Qu'essayez-vous de faire ? Où cherchez-vous à faire des gains ? Quel type de Lean pratiquez-vous actuellement ? Quel genre d'Agilité votre nouveau chef veut-il que vous fassiez ? Pas de conseil : ça dépend !

Métaposition

Fabrice Aimetti — Fri, 31 Jul 2026 09:08:34 GMT

Fabrice Aimetti :

[[Catégorie:Portail_Coach%27Agile]]
[[Catégorie:Supervision]]
Auteur : Michel Moral 
Source : [https://www.linkedin.com/in/michel-moral-msc-phd-8a86425 One skill that a coach, and even more so a supervisor, must acquire is "metaposition"] 
Date : 28/07/2026 
----
Traducteur : Fabrice Aimetti 
Date : 31/07/2026 
----
''Traduction :'' 
 
Une compétence qu’un coach, et plus encore un superviseur, doit acquérir est la "métaposition". 
 
Comme l’illustre l’image, cela implique une dissociation entre le professionnel qui est activement engagé dans l’action et celui qui observe et réfléchit. En France, on appelle cela la *métaposition*. 
 
L’observation porte sur soi-même en action, sur la personne coachée ou supervisée (ou le groupe), sur l’interaction entre eux, et enfin, sur le système lui-même. 
 
C’est une tâche assez exigeante qui requiert une grande attention, et donc une pratique approfondie, mais qui permet de discerner les éléments essentiels.
Une façon de s’y entraîner consiste à faire passer la détection des éléments notables du Système 2 (processus contrôlé) au Système 1 (processus automatique). 
 
Par exemple, au début de ma carrière de coach (il y a 22 ans), il m’arrivait parfois de m’ennuyer pendant les séances, au point de m’endormir (même si cela ne s’est produit qu’une seule fois). Mon superviseur m’a demandé de noter ces moments d’ennui et ce qui se passait chez la personne coachée au même moment. 
 
Une analyse détaillée de mes notes avec mon superviseur a révélé que cet ennui survenait avec des clients présentant des signes de dépression ou de dépression cachée. 
 
Quelle découverte ! Je suis passé du simple fait de m’ennuyer à celui de surveiller l’apparition de l’ennui, ce qui m’a permis de mettre au point un détecteur personnel et automatique, fonctionnant en temps réel et extrêmement fiable. 
 
J’ai ensuite développé une petite boîte à outils de détecteurs destinés à la projection, ainsi qu’à l’identification des personnalités narcissiques, des traits histrioniques, etc. Avec quelques outils et beaucoup de travail, la "métaposition" devient une posture naturelle pour le coach et surtout pour le superviseur. 
 
[[Fichier:Metaposition Cungi's Bike FR.jpg|border|link=|800px]]
----
[[Fichier:Metaposition Cungi's Bike EN.jpeg|border|link|800px]]

Métaposition

Fabrice Aimetti — Fri, 31 Jul 2026 09:06:07 GMT

Fabrice Aimetti : Page créée avec « Catégorie:Portail_Coach%27Agile Catégorie:Supervision Auteur : Michel Moral Source : [https://www.linkedin.com/in/michel-moral-msc-phd-8a86425 One skill that a coach, and even more so a supervisor, must acquire is "metaposition"] Date : 28/07/2026 ---- Traducteur : Fabrice Aimetti Date : 31/07/2026 ---- ''Traduction :'' 800px ---- Fichier:Metaposition... »

Fichier:Metaposition Cungi's Bike EN.jpeg

Fabrice Aimetti — Fri, 31 Jul 2026 09:05:46 GMT

Fabrice Aimetti :

Fabrice Aimetti — Thu, 23 Jul 2026 09:21:44 GMT

Fabrice Aimetti :

Le Poster du Processus de Responsabilité

Fabrice Aimetti — Fri, 17 Jul 2026 10:44:57 GMT

Fabrice Aimetti :

[[Category: Yves Hanoulle]]
[[Category: Philippe Launay (rip)]]
[[Category: Pablo Pernot]]
[[Category: Christopher Avery]]
[[Category: Portail Coach'Agile]]
[[Category: Processus de responsabilité]]
Auteur : Christopher Avery 
Source : [http://www.christopheravery.com/responsibility-process-poster The Responsibility Process Poster] 
----
Traducteurs : Yves Hanoulle, Philippe Launay et Pablo Pernot 
Date : 07/04/2019 
----
Traduction : 
 
'''Une grande partie de ce que vous savez sur le leadership et la responsabilité personnelle est sur le point d'être remise en cause''' Le processus de responsabilité™, qui fait suite à des études de terrain, illustre comment les gens traitent leurs pensées afin d'éviter ou de prendre la responsabilité. Cela constitue le coeur du [http://www.christopheravery.com/the-leadership-gift Leadership Gift]™. Avoir conscience du Processus de Responsabilité fournit un cadre d'apprentissage pour les individus, les équipes et les organisations. C'est le premier modèle qui explique comment prendre, enseigner et inspirer la responsabilité personnelle, le principe de succès n°1 dans toute entreprise. 

* Responsabilité : Détenir complète capacité et puissance à créer, choisir, et attirer.
* Quitter : Abandonner pour éviter la Culpabilité et l'Obligation.
* Obligation : Faire ce que vous avez à faire au lieu de ce que vous voulez.
* Culpabilité : Rejeter le blâme sur soi-même (souvent ressenti comme la Honte).
* Justification : Se servir d'excuses pour expliquer la manière dont sont les choses.
* Accusation : Blâmer les autres pour ce qu'ils ont provoqué.
* Déni : Ignorer l'existence de quelque chose.
 '''Personne ne pense à la responsabilité personnelle quand les choses vont bien''' Quand quelque chose ne va pas, que ce soit grave ou non (par exemple, perdre des clés ou perdre un plan d'épargne retraite), le Processus de Responsabilité entre en jeu. Le processus mental propose l'Accusation comme motif. Si vous acceptez l'accusation comme une raison suffisante, alors vous agirez sur cette accusation. Si vous ne l'acceptez pas, alors votre processus mental vous propose une excuse (Justification). Et ainsi de suite. Ainsi, prendre la Responsabilité Personnelle est un processus par étapes qui correspond à refuser de donner suite à une série de pensées irresponsables que votre processus mental vous propose. 

* La responsabilité n'est pas seulement un trait de caractère / défaut. C'est un processus mental qui opère de la même manière chez tout le monde.
* Le processus peut être observé, appris, enseigné, étudié, développé, modélisé et pratiqué.
* Toute personne, équipe ou organisation volontaire peut pratiquer la responsabilité à des niveaux toujours plus élevés.
* Le Processus de Responsabilité est très utile lorsqu'on se l'applique. Il se retourne contre soi lorsqu'on l'utilise pour Accuser les autres.
 '''Libérer et maîtriser le Processus de Responsabilité™''' Les clés de la Responsabilité™, c'est-à-dire libérer et maîtriser la responsabilité par une pratique quotidienne sont : 

* INTENTION - L'intention de réagir à partir de l'état mental de Responsabilité lorsque les choses vont mal.
* PRISE DE CONSCIENCE - Repérer dans quel état mental vous êtes : Déni, Accusation, Justification, Culpabilité, Obligation, ou Fuite.
* CONFRONTATION - Vous faire face pour voir ce qui est réel, que vous pouvez apprendre, corriger ou améliorer.
 '''Essayez-le''' Utilisez le formulaire en haut à droite du site pour télécharger, imprimer et afficher une copie du poster du Processus de Responsabilité là où vous le verrez fréquemment. Cela vous surprendra de constater combien il soutient votre intention, votre prise de conscience, et même votre capacité à vous confronter. Essayez-le. [https://responsibility.com/the-responsibility-process-poster/ Le Processus de Responsabilité (poster)] 
 
[[Fichier:FrenchPoR.gif|border|link=]]

Framework Scrum (poster 2020)

Fabrice Aimetti — Fri, 17 Jul 2026 10:41:42 GMT

Fabrice Aimetti :

[[Category: Portail Framework]]
[[Category: Scrum]]
[[Catégorie:Barry Overeem]]
Auteurs : Barry Overeem et Thea Schukken 
Source : [https://shop.theliberators.com/products/scrum-framework-pdf Scrum Framework Poster] 
Date : 19/11/2020 
----
Traducteur : Fabrice Aimetti 
Date : 19/11/2020 
----
Traduction : 
 
En collaboration avec Thea Schukken, nous avons créé un schéma du Framework Scrum. Notre intention était d'uniquement capturer les parties essentielles du framework :
* Le "pourquoi" avec une petite bande dessinée.
* Les rôles, les artefacts et les événements dans une grande vue d'ensemble.
* Les valeurs et l'empirisme dans les fondations.
 
[[Fichier:Scrum_Framework_2020_fr_vignette.png|1000px|border|link=https://www.wikiagile.coach/images/0/0c/Scrum_Framework_2020_fr_resized.pdf|border]]

Cf. [[Mise à jour Scrum 2020]]
----
[[Fichier:Scrum Framework 2020 en vignette.png|1000px|border|link=]]

C'est quoi la cadence dans le Kanban ?

Fabrice Aimetti — Fri, 26 Jun 2026 19:53:22 GMT

Fabrice Aimetti : Fabrice Aimetti a déplacé la page C'est quoi, la cadence dans le Kanban ? vers C'est quoi la cadence dans le Kanban ? sans laisser de redirection

[[Category: Portail Framework]]
[[Category: Kanban]]
Auteur : Alex Zhezherau 
Source : [https://www.wrike.com/kanban-guide/faq/what-is-kanban-cadence/ What Is Kanban Cadence?] 
Date : 17/03/2026 
----
Traducteur : Fabrice Aimetti 
Date : 14/06/2026 
----
Traduction : 
 
Dans une organisation Agile, la cadence Kanban désigne le flux et le rythme des réunions Kanban. Ces réunions ne se déroulent pas de la même manière que dans Scrum. Chaque membre de l'équipe est libre d'y participer sans s'engager à assister à des réunions régulières à durée fixe. 
 
L'objectif de la cadence Kanban est de maintenir un rythme régulier de réunions afin de garantir que les équipes puissent atteindre les objectifs fixés et fournir le meilleur produit ou support possible à l'utilisateur final. 
 
La cadence Kanban comprend un ensemble de sept réunions réparties en trois groupes (boucles de rétroaction). Ces groupes de réunions sont les suivants :
* Accomplir les tâches
* Faire ce qui doit être fait
* Améliorer le flux de travail
 
Si certains praticiens Agile peuvent qualifier ces réunions planifiées de "cérémonies Kanban", la méthode Kanban utilise spécifiquement des cadences pour établir un rythme régulier sans avoir besoin d’un sprint timeboxé. 
 
Les sept réunions de cadence Kanban sont les suivantes :
* '''Réunions quotidiennes debout''' (''daily standup meeting'') :
** Tous les jours, 10 à 15 minutes, coordonner le flux sur le tableau et résoudre rapidement les obstacles.
** L'équipe se concentre sur le travail, et non sur les personnes, et se concentre sur ce qui doit être traité ensuite.

* '''Réunion hebdomadaire de réapprovisionnement/engagements''' (''weekly replenishment/commitments meeting'') :
** De manière hebdomadaire ou bihebdomadaire, 30 à 60 minutes, décider quel travail doit entrer dans le système ensuite en fonction de politiques claires, de la capacité et des risques.
** C’est là que vous évitez que le tableau ne devienne une simple liste de souhaits.

* '''Réunion de planification des livraisons''' (''delivery planning meeting'') :
** Toutes les 2 à 4 semaines, planifier les livraisons ou les versions à court terme et identifier les principales dépendances.
** Utilisez cet outil pour vous assurer que vous êtes réellement en mesure de livrer ce qui est prévu, et pas seulement d'en parler.

* '''Revue bihebdomadaire des livraisons''' (''bi-weekly service delivery review'') :
** Toutes les deux semaines, évaluer la performance du service à l'aide d'indicateurs tels que le lead time, le on-time delivery et la prédictibilité.
** C'est l'occasion de se demander : "sommes-nous fiables ?" et d'étayer cette affirmation par des données.

* '''Revue mensuelle des risques''' (''monthly risk review'') :
** Mensuellement, identifier et traiter les risques systémiques qui ralentissent le flux ou compromettent les résultats.
** Au lieu de traiter chaque problème comme un cas isolé, on recherche des tendances et on s'attaque aux causes profondes.

* '''Réunion bimestrielle de revue des opérations''' (''bi-monthly operations review meeting'') :
** De manière mensuelle ou bimestrielle, équilibrer la demande et les capacités entre les équipes et les services.
** C’est l’occasion de repérer les surcharges, de négocier les capacités et de fluidifier le travail à l’échelle du système.

* '''Revue trimestrielle de la stratégie''' (''quarterly strategy review'') :
** Trimestriellement, aligner les choix/paris du portefeuille et les initiatives majeures sur les signaux du marché et sur ce que vos services sont réellement en mesure de livrer.
** Cela permet de maintenir le lien entre votre système Kanban et la stratégie business réelle, et non pas uniquement la file d'attente en cours.
 
Chaque réunion répond à un objectif particulier au sein de l'organisation. 
 
[[Fichier:Kanban-cadences.jpg|border|link=|800px]]

C'est quoi la cadence dans le Kanban ?

Fabrice Aimetti — Sun, 14 Jun 2026 20:39:20 GMT

Fabrice Aimetti :

C'est quoi la cadence dans le Kanban ?

Fabrice Aimetti — Sun, 14 Jun 2026 20:00:27 GMT

Fabrice Aimetti :

[[Category: Portail Framework]]
[[Category: Kanban]]
Auteur : Alex Zhezherau 
Source : [https://www.wrike.com/kanban-guide/faq/what-is-kanban-cadence/ What Is Kanban Cadence?] 
Date : 17/03/2026 
----
Traducteur : Fabrice Aimetti 
Date : 14/06/2026 
----
Traduction : 
 
Dans une organisation Agile, la cadence Kanban désigne le flux et le rythme des réunions Kanban. Ces réunions ne se déroulent pas de la même manière que dans Scrum. Chaque membre de l'équipe est libre d'y participer sans s'engager à assister à des réunions régulières à durée fixe. 
 
L'objectif de la cadence Kanban est de maintenir un rythme régulier de réunions afin de garantir que les équipes puissent atteindre les objectifs fixés et fournir le meilleur produit ou support possible à l'utilisateur final. 
 
La cadence Kanban comprend un ensemble de sept réunions réparties en trois groupes (boucles de rétroaction). Ces groupes de réunions sont les suivants :
* Accomplir les tâches
* Faire ce qui doit être fait
* Améliorer le flux de travail
 
Si certains praticiens Agile peuvent qualifier ces réunions planifiées de "cérémonies Kanban", la méthode Kanban utilise spécifiquement des cadences pour établir un rythme régulier sans avoir besoin d’un sprint timeboxé. 
 
Les sept réunions de cadence Kanban sont les suivantes :
* '''Réunions quotidiennes debout''' (''daily standup meeting'') :
** Tous les jours, 10 à 15 minutes, coordonner le flux sur le tableau et résoudre rapidement les obstacles.
** L'équipe se concentre sur le travail, et non sur les personnes, et se concentre sur ce qui doit être traité ensuite.

* '''Réunion hebdomadaire de réapprovisionnement/engagements''' (''weekly replenishment/commitments meeting'') :
** De manière hebdomadaire ou bihebdomadaire, 30 à 60 minutes, décider quel travail doit entrer dans le système ensuite en fonction de politiques claires, de la capacité et des risques.
** C’est là que vous évitez que le tableau ne devienne une simple liste de souhaits.

* '''Réunion de planification des livraisons''' (''delivery planning meeting'') :
** Toutes les 2 à 4 semaines, planifier les livraisons ou les versions à court terme et identifier les principales dépendances.
** Utilisez cet outil pour vous assurer que vous êtes réellement en mesure de livrer ce qui est prévu, et pas seulement d'en parler.

* '''Revue bihebdomadaire des livraisons''' (''bi-weekly service delivery review'') :
** Toutes les deux semaines, évaluer la performance du service à l'aide d'indicateurs tels que le lead time, le on-time delivery et la prédictibilité.
** C'est l'occasion de se demander : "sommes-nous fiables ?" et d'étayer cette affirmation par des données.

* '''Revue mensuelle des risques''' (''monthly risk review'') :
** Mensuellement, identifier et traiter les risques systémiques qui ralentissent le flux ou compromettent les résultats.
** Au lieu de traiter chaque problème comme un cas isolé, on recherche des tendances et on s'attaque aux causes profondes.

* '''Réunion bimestrielle de revue des opérations''' (''bi-monthly operations revie meeting'') :
** De manière mensuelle ou bimestrielle, équilibrer la demande et les capacités entre les équipes et les services.
** C’est l’occasion de repérer les surcharges, de négocier les capacités et de fluidifier le travail à l’échelle du système.

* '''Revue trimestrielle de la stratégie''' (''quarterly strategy review'') :
** Trimestriellement, aligner les choix/paris du portefeuille et les initiatives majeures sur les signaux du marché et sur ce que vos services sont réellement en mesure de livrer.
** Cela permet de maintenir le lien entre votre système Kanban et la stratégie business réelle, et non pas uniquement la file d'attente en cours.
 
Chaque réunion répond à un objectif particulier au sein de l'organisation. 
 
[[Fichier:Kanban-cadences.jpg|border|link=|800px]]

C'est quoi la cadence dans le Kanban ?

Fabrice Aimetti — Sun, 14 Jun 2026 20:00:15 GMT

Fabrice Aimetti :

[[Category: Portail Framework]]
[[Category: Kanban]]
Auteur : Alex Zhezherau 
Source : [https://www.wrike.com/kanban-guide/faq/what-is-kanban-cadence/ What Is Kanban Cadence?] 
Date : 17/03/2026 
----
Traducteur : Fabrice Aimetti 
Date : 14/06/2026 
----
Traduction : 
 
Dans une organisation Agile, la cadence Kanban désigne le flux et le rythme des réunions Kanban. Ces réunions ne se déroulent pas de la même manière que dans Scrum. Chaque membre de l'équipe est libre d'y participer sans s'engager à assister à des réunions régulières à durée fixe. 
 
L'objectif de la cadence Kanban est de maintenir un rythme régulier de réunions afin de garantir que les équipes puissent atteindre les objectifs fixés et fournir le meilleur produit ou support possible à l'utilisateur final. 
 
La cadence Kanban comprend un ensemble de sept réunions réparties en trois groupes (boucles de rétroaction). Ces groupes de réunions sont les suivants :
* Accomplir les tâches
* Faire ce qui doit être fait
* Améliorer le flux de travail
 
Si certains praticiens Agile peuvent qualifier ces réunions planifiées de "cérémonies Kanban", la méthode Kanban utilise spécifiquement des cadences pour établir un rythme régulier sans avoir besoin d’un sprint timeboxé. 
 
Les sept réunions de cadence Kanban sont les suivantes :
* '''Réunions quotidiennes debout''' (''daily standup meeting'') :
** Tous les jours, 10 à 15 minutes, coordonner le flux sur le tableau et résoudre rapidement les obstacles.
** L'équipe se concentre sur le travail, et non sur les personnes, et se concentre sur ce qui doit être traité ensuite.

* '''Réunion hebdomadaire de réapprovisionnement/engagements''' (''weekly replenishment/commitments meeting'') :
** De manière hebdomadaire ou bihebdomadaire, 30 à 60 minutes, décider quel travail doit entrer dans le système ensuite en fonction de politiques claires, de la capacité et des risques.
** C’est là que vous évitez que le tableau ne devienne une simple liste de souhaits.

* '''Réunion de planification des livraisons''' (''delivery planning meeting'') :
** Toutes les 2 à 4 semaines, planifier les livraisons ou les versions à court terme et identifier les principales dépendances.
** Utilisez cet outil pour vous assurer que vous êtes réellement en mesure de livrer ce qui est prévu, et pas seulement d'en parler.

* '''Revue bihebdomadaire des livraisons''' (''bi-weekly service delivery review'') :
** Toutes les deux semaines, évaluer la performance du service à l'aide d'indicateurs tels que le lead time, le on-time delivery et la prédictibilité.
** C'est l'occasion de se demander : "sommes-nous fiables ?" et d'étayer cette affirmation par des données.

* '''Revue mensuelle des risques''' (''monthly risk review'') :
** Mensuellement, identifier et traiter les risques systémiques qui ralentissent le flux ou compromettent les résultats.
** Au lieu de traiter chaque problème comme un cas isolé, on recherche des tendances et on s'attaque aux causes profondes.

* '''Réunion bimestrielle de revue des opérations''' (''bi-monthly operations revie meeting'') :
** De manière mensuelle ou bimestrielle, équilibrer la demande et les capacités entre les équipes et les services.
** C’est l’occasion de repérer les surcharges, de négocier les capacités et de fluidifier le travail à l’échelle du système.

* '''Revue trimestrielle de la stratégie''' (''quarterly strategy review'') :
** Trimestriellement, aligner les choix/paris du portefeuille et les initiatives majeures sur les signaux du marché et sur ce que vos services sont réellement en mesure de livrer.
** Cela permet de maintenir le lien entre votre système Kanban et la stratégie business réelle, et non pas uniquement la file d'attente en cours.
 
Chaque réunion répond à un objectif particulier au sein de l'organisation. 
 
[[Fichier:Kanban-cadences.jpg|border|link=]]

C'est quoi la cadence dans le Kanban ?

Fabrice Aimetti — Sun, 14 Jun 2026 20:00:00 GMT

Fabrice Aimetti :

[[Category: Portail Framework]]
[[Category: Kanban]]
Auteur : Alex Zhezherau 
Source : [https://www.wrike.com/kanban-guide/faq/what-is-kanban-cadence/ What Is Kanban Cadence?] 
Date : 17/03/2026 
----
Traducteur : Fabrice Aimetti 
Date : 14/06/2026 
----
Traduction : 
 
Dans une organisation Agile, la cadence Kanban désigne le flux et le rythme des réunions Kanban. Ces réunions ne se déroulent pas de la même manière que dans Scrum. Chaque membre de l'équipe est libre d'y participer sans s'engager à assister à des réunions régulières à durée fixe. 
 
L'objectif de la cadence Kanban est de maintenir un rythme régulier de réunions afin de garantir que les équipes puissent atteindre les objectifs fixés et fournir le meilleur produit ou support possible à l'utilisateur final. 
 
La cadence Kanban comprend un ensemble de sept réunions réparties en trois groupes (boucles de rétroaction). Ces groupes de réunions sont les suivants :
* Accomplir les tâches
* Faire ce qui doit être fait
* Améliorer le flux de travail
 
Si certains praticiens Agile peuvent qualifier ces réunions planifiées de "cérémonies Kanban", la méthode Kanban utilise spécifiquement des cadences pour établir un rythme régulier sans avoir besoin d’un sprint timeboxé. 
 
Les sept réunions de cadence Kanban sont les suivantes :
* '''Réunions quotidiennes debout''' (''daily standup meeting'') :
** Tous les jours, 10 à 15 minutes, coordonner le flux sur le tableau et résoudre rapidement les obstacles.
** L'équipe se concentre sur le travail, et non sur les personnes, et se concentre sur ce qui doit être traité ensuite.

* '''Réunion hebdomadaire de réapprovisionnement/engagements''' (''weekly replenishment/commitments meeting'') :
** De manière hebdomadaire ou bihebdomadaire, 30 à 60 minutes, décider quel travail doit entrer dans le système ensuite en fonction de politiques claires, de la capacité et des risques.
** C’est là que vous évitez que le tableau ne devienne une simple liste de souhaits.

* '''Réunion de planification des livraisons''' (''delivery planning meeting'') :
** Toutes les 2 à 4 semaines, planifier les livraisons ou les versions à court terme et identifier les principales dépendances.
** Utilisez cet outil pour vous assurer que vous êtes réellement en mesure de livrer ce qui est prévu, et pas seulement d'en parler.

* '''Revue bihebdomadaire des livraisons''' (''bi-weekly service delivery review'') :
** Toutes les deux semaines, évaluer la performance du service à l'aide d'indicateurs tels que le lead time, le on-time delivery et la prédictibilité.
** C'est l'occasion de se demander : "sommes-nous fiables ?" et d'étayer cette affirmation par des données.

* '''Revue mensuelle des risques''' (''monthly risk review'') :
** Mensuellement, identifier et traiter les risques systémiques qui ralentissent le flux ou compromettent les résultats.
** Au lieu de traiter chaque problème comme un cas isolé, on recherche des tendances et on s'attaque aux causes profondes.

* '''Réunion bimestrielle de revue des opérations''' (''bi-monthly operations revie meeting'') :
** De manière mensuelle ou bimestrielle, équilibrer la demande et les capacités entre les équipes et les services.
** C’est l’occasion de repérer les surcharges, de négocier les capacités et de fluidifier le travail à l’échelle du système.

* '''Revue trimestrielle de la stratégie''' (''quarterly strategy review'') :
** Trimestriellement, aligner les choix/paris du portefeuille et les initiatives majeures sur les signaux du marché et sur ce que vos services sont réellement en mesure de livrer.
** Cela permet de maintenir le lien entre votre système Kanban et la stratégie business réelle, et non pas uniquement la file d'attente en cours.
 
Chaque réunion répond à un objectif particulier au sein de l'organisation. 
 
[Fichier:Kanban-cadences.jpg|border|link=]

Fabrice Aimetti — Sun, 14 Jun 2026 19:23:15 GMT

Fabrice Aimetti : Page créée avec « Category: Portail Framework Category: Kanban Auteur : Alex Zhezherau Source : [https://www.wrike.com/kanban-guide/faq/what-is-kanban-cadence/ What Is Kanban Cadence?] Date : 17/03/2026 ---- Traducteur : Fabrice Aimetti Date : 14/06/2026 ---- Traduction : Dans une organisation Agile, la cadence Kanban désigne le flux et le rythme des réunions Kanban. Ces réunions ne se déroulent pas de la même manière que dans Scru... »

Présentation de la cartographie des exemples

Fabrice Aimetti — Mon, 08 Jun 2026 09:17:10 GMT

Fabrice Aimetti :

[[Category: Nicolas Mereaux]]
[[Category: Portail Product Owner]]
[[Category: Portail Equipe de développement]]
[[Category: Tests]]
[[Category: BDD]]
[[Category: Example Mapping]]
[[Catégorie:Story_Mapping]]
[[Category: Les traducteurs agiles]]
Auteur : [https://cucumber.io/#company Matt Wynne] 
Source : [https://cucumber.io/blog/2015/12/08/example-mapping-introduction Introducing Example Mapping] 
Date : 08/12/2015 
----
Traducteur : Nicolas Mereaux 
Date : 20/03/2017 
----
Traduction : 
 
Avant de mettre en développement une user story, avoir une conversation pour clarifier et valider les critères d’acceptation est vital. 
 
Certaines personnes le font pendant leurs sessions d’affinage de backlog ou de planning poker. D’autres équipes font une réunion spécifique des trois amigos, un atelier de spécification ou de découverte. 
 
http://www.les-traducteurs-agiles.org/2017/03/21/presentation-cartographie-des-exemples.html

Prêt égal fini

Fabrice Aimetti — Fri, 05 Jun 2026 15:01:33 GMT

Fabrice Aimetti :

[[Category: Nicolas Mereaux]]
[[Category: Portail Framework]]
[[Catégorie:DoD]]
[[Catégorie:DoR]]
[[Category: Les traducteurs agiles]]
Auteur : [http://aardrock.com/contact/martien-van-steenbergen/ Martien Van Steenbergen] 
Source : [http://aardrock.com/ready-equals-done/ Ready equals done] 
Date : 02/04/2011 
----
Traducteur : Nicolas Mereaux 
Date : 11/02/2015 
----
Traduction : 
 
Scrum fait beaucoup de bruit autour de la définition de prêt et la définition de fini. 
 
Pour la phase en cours, la définition de prêt correspond à la définition de fini de la phase précédente. De la même manière, la définition de fini de la phase en cours correspond à la définition de prêt pour la prochaine. Ce sont les deux côtés d’une même membrane. 
 
http://www.les-traducteurs-agiles.org/2015/02/11/pret-egal-fini.html

Estimer en comparant avec l’expérience passée

Fabrice Aimetti — Fri, 01 May 2026 09:40:04 GMT

Fabrice Aimetti :

[[Category: Nicolas Mereaux]]
[[Category: Portail Exactimation]]
[[Category: George Dinwiddie]]
[[Category: Les traducteurs agiles]]
Auteur : [http://blog.gdinwiddie.com/about/ George Dinwinddie] 
Source : [http://blog.gdinwiddie.com/2015/12/12/estimating-in-comparison-to-past-experience/ Estimating in Comparison to Past Experience] 
Date : 12/12/2015 
----
Traducteur : Nicolas Mereaux 
Date : 29/01/2016 
----
Traduction : 
 

''La méthode la plus simple d’estimation est de comparer le travail à venir avec l’expérience passée. Et tous, nous possédons de l’expérience que nous pouvons utiliser. La question importante qui se pose est : cette expérience est-elle pertinente ? La deuxième question étant : est-ce que nous nous rappelons clairement cette expérience ?'' 
 
[http://www.les-traducteurs-agiles.org/2016/01/29/estimer-en-comparant-avec-l-experience-passee.html Lire le suite...]

Estimer en comparant avec l’expérience passée

Fabrice Aimetti — Fri, 01 May 2026 09:39:03 GMT

Fabrice Aimetti :

[[Category: Nicolas Mereaux]]
[[Category: Portail Exactimation]]
[[Category: George Dinwiddie]]
[[Category: Les traducteurs agiles]]
Auteur : [http://blog.gdinwiddie.com/about/ George Dinwinddie] 
Source : [http://blog.gdinwiddie.com/2015/12/12/estimating-in-comparison-to-past-experience/ Estimating in Comparison to Past Experience] 
Date : 12/12/2015 
----
Traducteur : Nicolas Mereaux 
Date : 29/01/2016 
----
Traduction : 
 

''La méthode la plus simple d’estimation est de comparer le travail à venir avec l’expérience passée. Et tous, nous possédons de l’expérience que nous pouvons utiliser. La question importante qui se pose est : cette expérience est-elle pertinente ? La deuxième question étant : est-ce que nous nous rappelons clairement cette expérience ?'' 
 
http://www.les-traducteurs-agiles.org/2016/01/29/estimer-en-comparant-avec-l-experience-passee.html

Wiki Agile

Fabrice Aimetti — Fri, 01 May 2026 09:38:24 GMT

Fabrice Aimetti :

Bienvenue sur [[Wiki_Agile:À_propos_de|ce wiki]] qui rassemble '''{{NUMBEROFPAGES}}''' ressources sur l'Agilité, le Lean, le Product Management, le Coaching, ... et bien d'autres choses depuis le [[Serial_Traducteur|24 mai 2009]]. Vous n'êtes pas là par hasard. Vous aussi, vous pouvez devenir acteur de votre propre apprentissage !

Si vous souhaitez recevoir automatiquement les dernières traductions, il vous suffit de vous abonner au flux RSS [https://wikiagile.coach/nouvelles-pages.rss https://wikiagile.coach/nouvelles-pages.rss] avec votre agrégateur préféré.

Si vous souhaitez contribuer en apportant ou en référençant l'une de vos traductions sur ce wiki, [mailto:fabrice@ayeba.fr?subject=Wiki%20Agile contactez-moi].

=={{int:license-header}}==
{{CC-BY-SA}}


==Les 20 dernières ressources mises en ligne==
{| class="wiki_table"
|- style="vertical-align:top;"
|[[Image:news_48.png|link=]] 
|{{Special:Newestpages/-/20}}
|}

 

==Portails thématiques==


{| class="wiki_table"
|
[[Image:book_48.png|link=Catégorie:Portail_Livres_de_chevet]] 
|'''[[:Catégorie:Portail_Livres_de_chevet|Livres et mini-livres de chevet]]''' À la découverte des livres et mini-livres de référence traduits par et pour la communauté. Dernier en date : [[Réussir_avec_les_OKR_en_Agile_(le_livre)|Réussir avec les OKR en Agile (le livre)]]
|-
| 
| 
|-
|
[[Fichier:Couteau-suisse-2.png|link=Catégorie:Portail_Leçons_de_coaching_agile|54px]] 
|'''[[:Catégorie:Portail%20Le%C3%A7ons%20de%20coaching%20agile|Leçons de Coaching Agile]]''' À la découverte des leçons de Coaching Agile mises à la disposition des coachs Agile à travers le monde par Daniel Mezick.
|[[Fichier:DanMezick.png|50px|link=https://twitter.com/danielmezick]]
|-
| 
| 
|-
|
[[Image:clinic_48.png|link=Catégorie:Portail_Coach_Clinic]] 
|'''[[:Catégorie:Portail%20Coach%20Clinic|Coach Clinic]]''' À la découverte de la Coach Clinic, des bulles de coaching pour croiser les expériences des coachs et des coachés. 
|-
| 
| 
|-
|
[[Image:LeSS-logo_48.png|link=Catégorie:Portail_LeSS]] 
|'''[[:Catégorie:Portail_LeSS|LeSS]]''' À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
|-
| 
| 
|-
|
[[Image:wallpaper-icon_48.png|link=Catégorie:Wallpapers]] 
|'''[[:Catégorie:Wallpapers|Wallpapers]]''' À la découverte des fonds d'écran que j'ai bidouillé en m'inspirant de ce qui circule dans le milieu de l'Agilité. 
|-
| 
| 
|-
|
[[Image:annibal_48.png|annibal_48.png|link=Catégorie:Portail_Product_Owner]] 
|'''[[:Catégorie:Portail_Product_Owner|Product Owner]]''' À la découverte du rôle de Product Owner, ce responsable de l'innovation des produits, et de ses pratiques. 
|-
| 
| 
|-
|
[[Image:murdock_48.png|murdock_48.png|link=Catégorie:Portail_ScrumMaster]] 
|'''[[:Catégorie:Portail_ScrumMaster|ScrumMaster]]''' À la découverte du rôle du ScrumMaster, ce facilitateur d'équipes, et de ses pratiques. 
|-
| 
| 
|-
|
[[Image:mario_48.png|mario_48.png|link=Catégorie:Portail_Equipe_de_développement]] 
|'''[[:Catégorie:Portail_Equipe_de_développement|Équipe de développement]]''' À la découverte du rôle du Développeur, ce co-équipier, cet "artisan" qui participe au développement du produit quelque soit sa discipline. 
|-
| 
| 
|-
|
[[Image:the_face_48.png|link=Catégorie:Portail Coach'Agile]] 
|'''[[:Catégorie:Portail Coach'Agile|Coach'Agile]]''' À la découverte du rôle du Coach'Agile, cet agent du changement, et de ses pratiques. 
|-
| 
| 
|-
|
[[Image:manager_48.png|link=Catégorie:Portail Manager-Leader Agile]] 
|'''[[:Catégorie:Portail Manager-Leader Agile|Manager-Leader Agile]]''' À la découverte du rôle du Manager-Leader Agile, le supporter de l'organisation et des équipes. 
|-
| 
| 
|-
|
[[Image:unclesam_48.png|link=Catégorie:Portail Organisation Agile]] 
|'''[[:Catégorie:Portail Organisation Agile|Organisation Agile]]''' À la découverte de l'organisation, une histoire que l'on se raconte à plusieurs et à laquelle on croit. 
|-
| 
| 
|-
|
[[Image:a_team_van_48.png|link=Catégorie:Portail Framework]] 
|'''[[:Catégorie:Portail Framework|Framework]]''' À la découverte des frameworks, ces modèles que nous utilisons, tordons et réinventons à souhait. 
|-
| 
| 
|-
|
[[Image:estimation_48.png|link=Catégorie:Portail_Exactimation]] 
|'''[[:Catégorie:Portail_Exactimation|Exactimation]]''' À la découverte des techniques d'estimation et de ses travers... 
|-
| 
| 
|-
|
[[Image:planification_48.png|link=Catégorie:Portail Planification]] 
|'''[[:Catégorie:Portail Planification|Planification]]''' À la découverte des techniques de planification, la différence entre un rêve et un projet c'est une date... 
|-
| 
| 
|-
|
[[Image:switchoffon_72.gif|link=Catégorie:Portail Contrat-Pilote]] 
|'''[[:Catégorie:Portail Contrat-Pilote|Contrat - Projet Pilote]]''' À la découverte des modes de contractualisation Agile et de l'éligibilité d'un projet pilote Agile. 
|-
| 
| 
|-
|
[[Image:lean_48.png|link=Catégorie:Portail Lean]] 
|'''[[:Catégorie:Portail Lean|Lean]]''' À la découverte du Lean, ou plus simplement du système d'apprentissage Toyota. 
|-
| 
| 
|-
|
[[Image:startup_48.png|link=Catégorie:Portail Startup]] 
|'''[[:Catégorie:Portail Startup|Startup]]''' À la découverte de l'esprit startup, qui stimule l'innovation et rend plus réactif. 
|-
| 
| 
|-
|
[[Image:post-it_48.png|link=Catégorie:Portail Facilitation]] 
|'''[[:Catégorie:Portail Facilitation|Facilitation]]''' À la découverte de la facilitation, de sa posture et des ses outils. 
|-
| 
| 
|-
|
[[Image:icebreaker-48.png|link=Catégorie:Portail Icebreakers]] 
|'''[[:Catégorie:Portail Icebreakers|Icebreakers]]''' À la découverte des icebreakers, ces brise-glaces qui énergisent et connectent les personnes. 
|-
| 
| 
|-
|
[[Image:stormtrooper_48.png|link=Catégorie:Portail_Scrumtrooper - Légende]] 
|'''[[:Catégorie:Portail Scrumtrooper - Légende|Scrumtrooper - Légende]]''' À la découverte de la légende (et des posters) des Scrumtroopers par Ilan Goldstein.
|[[Fichier:Ilagile.png|50px|link=https://twitter.com/ilagile]] 
|-
| 
| 
|-
|
[[Image:halloffame_48.png|link=Catégorie:Mur des célébrités]] 
|'''[[:Catégorie:Mur des célébrités|Mur des célébrités]]''' À la découverte des anglophones que nous suivons et traduisons régulièrement. 
|-
| 
| 
|-
|
[[Image:Red-Flower-icon.png|48px|link=Catégorie:Contributeurs_à_ce_wiki]] 
|'''[[:Catégorie:Contributeurs à ce wiki|Contributeurs à ce wiki]]''' Mise en avant des contributeurs qui permettent de rendre ce wiki plus riche, et notamment Nicolas Mereaux.
|[[Fichier:Nime.png|50px|link=https://twitter.com/__nime__]] 
|-
| 
| 
|-
|
[[Image:Random-page-48px.png|link=Special:Page_au_hasard]] 
|'''[[Special:Page_au_hasard|Sérendipité]]''' Si vous ne savez pas par où commencer... laissez la place à l'heureux hasard ! 
|}

Si vous souhaitez soutenir le projet, c'est par ici : [[Fichier:Don-paypal.png|link=https://www.paypal.com/donate/?hosted_button_id=N95MASZP54WP8|100px]]