Agilité hors IT : ce qui marche, ce qui ne marche pas

# Agilité hors IT : ce qui marche, ce qui ne marche pas

Le service RH annonce qu’il passe « en mode agile ». Deux semaines plus tard, l’équipe a un backlog, un daily de quinze minutes et un tableau plein de post-its. Les gens parlent de sprints pour désigner leurs recrutements en cours.

Trois mois après, le daily est devenu un tour de table où chacun récite son agenda. Le backlog n’est plus mis à jour. Les post-its jaunissent.

Personne n’ose le dire tout haut, mais tout le monde le pense : ce truc a été inventé pour des développeurs, pas pour nous.

C’est vrai et c’est faux. L’agilité hors informatique fonctionne. Ce qui ne fonctionne pas, c’est la manière dont on l’exporte. Voici ce qui se transpose vraiment, ce qui casse en route, et comment éviter le piège du copier-coller.

L’agilité hors informatique, de quoi on parle

L’agilité hors informatique consiste à appliquer les principes agiles à des équipes qui ne produisent pas de logiciel : RH, marketing, finance, juridique, industrie, services. Ce qui se transpose, c’est la posture : boucles courtes, décisions rapprochées du terrain, travail rendu visible. Ce qui ne se transpose pas, c’est le rituel calqué tel quel depuis le monde du développement.

Cette distinction change tout. Elle sépare les équipes qui gagnent en clarté de celles qui héritent d’un folklore.

Le Manifeste agile a été écrit en 2001 par des gens du logiciel, pour du logiciel. Ses quatre valeurs parlent de logiciel opérationnel et de collaboration avec le client. Mais lisez-le de près : les principes derrière les mots dépassent largement le code. Livrer souvent. Ajuster en fonction de ce qu’on apprend. Faire confiance à ceux qui font le travail.

Rien de tout ça n’appartient aux développeurs. Tout ça appartient à n’importe quel collectif qui travaille dans l’incertitude.

Le problème commence quand on confond les principes avec leur emballage d’origine.

Ce qui se transpose partout

Trois choses voyagent bien hors du logiciel. Trois choses seulement, mais elles portent l’essentiel de la valeur.

Remarquez ce qui relie ces trois éléments : aucun ne demande de vocabulaire technique. Aucun ne demande de cérémonie importée. Ils demandent un changement de rapport au travail, pas un changement de décor.

C’est exactement ce que recouvre l’état d’esprit agile : un rapport à l’incertitude, à l’erreur et à la décision. Ce rapport-là se travaille dans une usine, un cabinet juridique ou une direction communication. Le métier ne change rien à l’affaire.

Ce qui ne se transpose pas

Maintenant, la partie qui fâche. Deux choses ne survivent pas au voyage hors du logiciel. Et ce sont précisément celles qu’on exporte en premier.

Les rituels calqués sans traduction

Le sprint de deux semaines a un sens en développement logiciel : à la fin, on livre un incrément qui fonctionne. Le rythme découle de la nature du travail.

Un service RH ne livre pas un incrément toutes les deux semaines. Un recrutement prend six semaines. Une négociation annuelle prend trois mois. Un dossier disciplinaire suit son propre tempo, imposé par le droit. Plaquer un sprint là-dessus, c’est découper artificiellement un travail qui ne se découpe pas comme ça.

Résultat classique : des « sprints » qui ne livrent rien, des revues où on montre du travail en cours, et une équipe qui joue la comédie du cadre. Le rituel tourne à vide. Il coûte du temps sans rendre de clarté.

Le daily subit le même sort. En développement, il synchronise des gens qui travaillent sur le même produit et se bloquent mutuellement. Dans un service où chacun gère ses propres dossiers, le daily devient un tour de table de reporting. Chacun parle à son manager, pas à ses collègues. Quinze minutes par jour pour ça, c’est cher payé.

Le vocabulaire tech plaqué sur le métier

Backlog, sprint, product owner, vélocité, story points. Ce vocabulaire a une histoire et un contexte. Sorti de ce contexte, il produit deux effets, tous les deux mauvais.

Premier effet : il exclut. Une chargée de recrutement qui doit appeler ses dossiers des « user stories » sent bien qu’on lui impose la langue d’un autre métier. Le message implicite est violent : votre façon de nommer votre travail ne vaut rien, prenez la nôtre.

Deuxième effet : il masque. Derrière le vocabulaire importé, on croit avoir changé les pratiques. On a changé les mots. Le dossier s’appelle une story, il est traité exactement comme avant. Le théâtre a juste gagné un lexique.

Le piège du copier-coller Scrum

Soyons clairs sur un point : Scrum n’est pas le problème. C’est un cadre honnête, pensé pour un contexte précis, le développement de produits complexes. Bien utilisé dans ce contexte, il rend de vrais services.

Le problème, c’est le réflexe du copier-coller. Une direction décide que « toute la boîte passe agile ». Et comme Scrum est le cadre le plus connu, on déploie Scrum partout. Y compris là où rien ne s’y prête.

Pourquoi ce réflexe est-il si répandu ? Parce que copier un cadre est rassurant. Il y a un guide, des rôles, des cérémonies, des formations sur étagère. On peut montrer un plan de déploiement. Alors que traduire des principes dans un métier, ça demande de réfléchir. Ça demande de comprendre le travail réel de l’équipe. C’est plus lent, moins visible, moins vendable en comité.

Les travaux de Snowden sur les contextes de décision éclairent bien ce piège. Les pratiques utiles dépendent de la nature du problème. Appliquer une recette unique à des contextes différents, c’est la définition même de l’erreur de domaine. Un processus de paie, très ordonné, n’appelle pas le même traitement qu’un repositionnement de marque, largement imprévisible. Scrum partout, c’est ignorer cette différence.

Le copier-coller produit une conséquence durable et sous-estimée : il vaccine. Une équipe marketing qui a subi six mois de faux sprints ne dira plus jamais oui à une démarche agile. Même bien conçue. Même utile. Le mot est grillé pour des années. On ne mesure jamais ce coût-là dans les bilans de transformation.

Comment démarrer dans une équipe non tech

Alors, comment faire pour de vrai ? Quatre mouvements, dans cet ordre.

Partir d’un irritant réel, pas d’un cadre

Ne demandez pas « comment installer l’agilité chez nous ». Demandez « qu’est-ce qui nous fait perdre du temps, de l’énergie ou de la qualité en ce moment ». Les dossiers qui traînent, les validations qui s’empilent, les urgences qui écrasent tout. L’irritant désigne le point d’entrée. Le cadre viendra après, s’il vient.

Rendre le travail visible avant de le changer

Un tableau simple : à faire, en cours, bloqué, terminé. Avec les mots de l’équipe, pas ceux d’un guide. Deux semaines d’observation suffisent souvent à faire apparaître ce que personne ne voyait : la surcharge chronique, le goulot d’étranglement, les tâches fantômes. On ne change bien que ce qu’on voit.

Installer une boucle de retour, au rythme du métier

Pas un sprint de deux semaines parce que c’est écrit quelque part. Un rendez-vous régulier où l’équipe regarde ce qui a avancé, ce qui bloque, et décide d’un ajustement. Toutes les semaines, toutes les trois semaines, peu importe. Le bon rythme, c’est celui du travail réel.

Faire accompagner les débuts par quelqu’un qui facilite

Les premiers temps collectifs sont fragiles. Une réunion d’ajustement mal menée redevient une réunion de reporting en trois séances. La différence se joue sur la capacité à faire parler l’équipe de ses vrais sujets. C’est un travail de facilitation, pas de récitation de framework. J’ai détaillé cette distinction dans coach agile ou facilitateur.

Et si vous voulez poser le socle avant de vous lancer, une journée sur les fondamentaux suffit pour aligner l’équipe sur la posture. C’est exactement ce que travaille la formation agile Insuffle Académie : le rapport à l’incertitude d’abord, les outils ensuite, remis à leur place. Pour choisir plus largement un dispositif de formation qui tient la route, le guide pour choisir une formation agile pose les critères.

Une dernière chose. Si votre équipe RH ou marketing gagne en clarté avec un tableau, des boucles courtes et des décisions prises plus près du terrain, elle est agile. Qu’elle prononce le mot ou pas. Le vocabulaire n’a jamais été le sujet.

Découvrir la formation agile Insuffle Académie