Sauf dispositions contraires (cf. Politiques), vous pouvez démissionner à tout moment d’un rôle que vous remplissez en notifiant le Product Owner de votre cercle.
Cela ne signifie pas pour autant que vous quittez l’équipe : vous pouvez parfaitement continuer à énergiser d’autres rôles, voire demander à prendre un ou plusieurs nouveaux rôles.
Lorsqu’un rôle est laissé vacant, c’est au Product Onwer de l’énergiser tant qu’il n’a pas affecté ce rôle à une autre personne.
PLUS DE DÉTAILS SUR L'ARTICLE
Peut-on changer de rôle ou arrêter un rôle ? Oui, et c'est même souhaitable
Dans la méthode agile ias.a, les rôles ne sont pas des postes figés. Ils sont des responsabilités vivantes, attribuées à des personnes qui les « énergisent » c'est-à-dire qui leur donnent vie au quotidien par leurs actions et leurs décisions. Mais que se passe-t-il quand un rôle ne correspond plus ? Quand les compétences évoluent, quand le projet change de direction, quand un membre de l'équipe souhaite explorer d'autres territoires ? La réponse est claire : oui, on peut changer de rôle. Oui, on peut arrêter un rôle. Et c'est même l'un des signes de bonne santé d'une équipe agile.
Le rôle n'est pas le poste
Pour bien comprendre cette flexibilité, il faut d'abord saisir la différence fondamentale entre un rôle et un poste. Un poste est une case dans un organigramme. Il est défini une fois, souvent lors d'un recrutement, et change rarement. Un rôle, dans la logique de l'holacratie et de la méthode ias.a, est une unité de responsabilité définie par trois éléments : une raison d'être (pourquoi ce rôle existe), des redevabilités (les actions récurrentes que l'on attend du porteur) et éventuellement des domaines (les activités qui relèvent exclusivement de ce rôle).
Une personne peut porter plusieurs rôles. Et un rôle peut changer de porteur au fil du temps. Cette souplesse est au cœur du modèle : elle permet à l'organisation de s'adapter en continu sans avoir besoin de restructurations lourdes.
Comment ça se passe concrètement ?
Dans la méthode ias.a, c'est le Product Owner qui affecte les rôles aux membres de l'équipe. Il peut changer l'allocation des rôles structurels comme des rôles liés au projet. Cette décision n'est pas arbitraire elle se fonde sur l'observation des compétences, des appétences et des besoins du projet.
Sauf dispositions contraires définies dans les politiques de l'équipe, chaque membre peut également démissionner d'un rôle à tout moment. C'est un droit fondamental dans le système. Un collaborateur qui sent qu'il n'est plus le bon porteur d'un rôle parce que ses compétences sont mieux utilisées ailleurs, parce qu'il manque de motivation, ou parce que le contexte a changé peut en informer l'équipe et libérer le rôle.
Cette possibilité de démission n'est pas un aveu d'échec. C'est un acte de responsabilité. Dans un système où la transparence et l'auto-organisation sont des valeurs cardinales, reconnaître qu'on n'est pas ou plus la bonne personne pour un rôle est un signe de maturité, pas de faiblesse.
Le processus de gouvernance
Les changements de rôles peuvent être traités lors des réunions de gouvernance, ces espaces structurés où l'équipe ajuste son organisation. Lors de ces réunions, inspirées de l'holacratie et de la sociocratie 3.0, les membres peuvent proposer la création de nouveaux rôles, la modification de rôles existants, ou la suppression de rôles devenus obsolètes.
Le processus est structuré : proposition, clarification, réaction, traitement des objections par consentement (et non par consensus), puis décision. Ce cadre permet des ajustements rapides et fluides, sans les lourdeurs d'une réorganisation classique.
Un exemple courant : au début d'un projet, un rôle « veille concurrentielle » peut être essentiel. Quelques sprints plus tard, la veille est faite, les insights sont capitalisés, et le rôle n'a plus de raison d'être. Au lieu de le maintenir artificiellement, l'équipe le supprime ou le réaffecte. L'organisation reste légère, adaptée aux besoins réels du moment.
Les rôles qui « dorment »
Il arrive aussi que certains rôles n'aient pas d'utilité pendant une période. Un rôle « dépôt de brevet », par exemple, peut être actif lors des premiers sprints d'un projet d'innovation puis devenir dormant pendant la phase d'expérimentation. La personne qui porte ce rôle peut alors informer l'équipe de son souhait de ne pas assister aux stand-up meetings pendant cette période, tout en restant disponible en cas de besoin.
Cette notion de rôle dormant est importante. Elle évite de surcharger les réunions de personnes qui n'ont pas de contribution active à apporter, tout en maintenant la disponibilité des compétences quand elles redeviennent nécessaires.
De la fiche de poste au portefeuille de rôles
La flexibilité des rôles transforme profondément la manière dont les collaborateurs vivent leur travail. Au lieu d'être enfermés dans une fiche de poste statique, ils gèrent un portefeuille de rôles qui évolue avec le projet et avec leurs propres compétences. Cette dynamique crée un sentiment d'autonomie et de responsabilité qui est l'un des moteurs les plus puissants de l'engagement.
Bien sûr, cette flexibilité ne va pas sans quelques précautions. Les transitions de rôles doivent être documentées pour assurer la continuité. Le porteur sortant doit transmettre les informations clés au porteur entrant. Et le Product Owner doit veiller à ce que les réaffectations ne créent pas de déséquilibres certains membres se retrouvant surchargés pendant que d'autres manquent de responsabilités.
La tension comme signal
Dans la logique ias.a, le besoin de changer de rôle se manifeste souvent sous la forme d'une tension cet écart entre « ce qui est » et « ce qui pourrait être ». Un collaborateur qui ressent que son rôle ne correspond plus à la réalité du projet, ou que ses compétences seraient mieux employées ailleurs, porte une tension. Les stand-up meetings et les réunions de gouvernance sont les espaces pour l'exprimer et la traiter.
C'est cette capacité d'adaptation continue, organique, non bureaucratique, qui fait la force des organisations agiles. Les rôles ne sont pas des cages ce sont des costumes que l'on enfile et que l'on quitte au service du projet et de l'équipe.
