N’importe quel outil sait dessiner un organigramme. La vraie question est autre : qui décide dans cette unité – et qui l’a confirmé ?
Le problème des organigrammes dessinés
Dans la plupart des projets, l’organigramme existe deux fois. Une fois comme diapositive créée il y a six mois, une fois comme savoir dans les têtes. La diapositive montre des cases avec des noms. Elle ne montre pas si la personne le sait, depuis quand elle est responsable, ni ce qui se passe quand elle quitte le projet.
Tant qu’on ne dessine que des cases, la vraie question reste sans réponse. Une image ne se cherche pas, ne se vérifie pas et ne se fait pas confirmer.
Ce que nous avons construit à la place
Dans TAOM Process Studio, l’organisation du projet est un modèle, pas une image. On gère des unités, des niveaux et des personnes – l’organigramme en est calculé : niveaux, liens, cases, lignes de personnes.
La différence en une phrase : on ne gère pas l’image, on gère la responsabilité – l’image en découle.
Le RACI sur la case, pas dans un tableau annexe
Chaque affectation porte un rôle :
A décide – porte la responsabilité, exactement une fois par objet
R réalise – peut apparaître plusieurs fois
C est consulté – on le questionne, mais il ne décide pas
I est informé – apprend le résultat
Ces lettres figurent dans la case, à la couleur de leur rôle. En regardant l’organigramme, on voit tout de suite où un A manque.
Voyez par vous-même
L’organigramme ci-dessous provient d’un programme de transformation : 35 unités, 109 affectations, quatre niveaux. Il n’a pas été recopié mais généré depuis le modèle – et s’affiche avec notre propre visionneuse, celle qui tourne aussi dans Confluence.
Trois choses qu’une image ne sait pas faire
1. Faire confirmer la responsabilité
Toute personne inscrite dans une organisation reçoit un courriel et confirme elle-même – ou s’y oppose. Jusque-là, le poste reste « ouvert ».
Une responsabilité que personne n’a acceptée n’est pas une responsabilité. C’est une supposition.
En cas de refus, la personne qui l’a inscrit en est informée – avec le nom, le rôle et le domaine, pas avec une adresse de courriel.
2. Chercher les lacunes
Comme l’organisation est un modèle, on peut l’interroger. Neuf questions prêtes à l’emploi révèlent les faiblesses habituelles :
| Question | Ce qu’elle trouve |
|---|---|
| Sans décideur | Unités où personne ne porte de A |
| Plusieurs décideurs | Deux personnes avec un A sur le même objet |
| Responsabilité à l’extérieur | Le A revient à un prestataire externe |
| Informé seulement | Unités où personne n’agit |
| Collaborateur IA avec un A | Un agent à qui l’on confie la décision au lieu de l’exécution |
Ce n’est pas une analyse accessoire – c’est la raison même pour laquelle l’organisation est gérée comme un modèle.
3. Intégrer les collaborateurs numériques
Les agents IA participent aux processus. Dans le modèle, ils forment une origine à part – identifiables, dénombrables, vérifiables. Une règle vaut particulièrement pour eux :
Un agent ne confirme pas lui-même. C’est son responsable qui répond de son emploi.
Un A sur un agent déclenche donc un avertissement. R, C et I sont admis.
Un modèle, quatre sorties
La même organisation quitte l’outil par quatre chemins – et aucun n’est une capture d’écran :
| Chemin | Ce qui arrive |
|---|---|
| HTML | page autonome avec la visionneuse, partageable par lien |
| pour imprimer et joindre | |
| Confluence | une page par unité, avec élaboration et vue qualité |
| PowerPoint | de vraies formes, modifiables dans le programme cible |
La présentation est le chemin le plus récent – et celui qui nous a le plus appris. Intégrer une image aurait été plus simple. Mais qui reçoit un graphique ne peut plus rien changer : ni déplacer une unité, ni corriger un nom, ni remanier une diapositive.
C’est pourquoi l’export crée de vraies formes. Chaque case est un groupe – un clic saisit le cadre, le bandeau, le titre et les lignes de personnes. Après la vue d’ensemble vient une diapositive par groupe, suivie directement des élaborations de ses unités. Ce qui va ensemble se tient ensemble.
Ce que cela change au quotidien
La différence n’apparaît pas le jour où l’organigramme est créé. Elle apparaît trois mois plus tard, quand quelqu’un demande : Qui était responsable de la migration des données, déjà ?
Avec une diapositive, la recherche commence. Avec un modèle tenu à jour, la réponse est dans la case – avec le rôle, la date de confirmation et la mention si personne n’a confirmé.
En bref
Un organigramme est la vue, pas la chose. Ce que l’on gère, c’est la responsabilité : qui décide, qui est consulté, qui a accepté. L’image en découle – et se laisse interroger, vérifier et transmettre.
Pour aller plus loin : Responsabilité & organisation du projet · RACI – qui décide, qui est consulté · Confirmer les rôles plutôt que les attribuer · Là où personne n’est responsable · Escalade et agents IA · Une source, plusieurs systèmes cibles
Laisser un commentaire