L'agilité est née dans le logiciel, mais ses principes s'appliquent à d'autres domaines où le besoin est incertain et où l'on gagne à avancer par petits pas.

Ce qui se transfère bien

• Travailler par itérations : découper un gros travail en incréments livrables et utiles.
• Un backlog priorisé : une liste de ce qui reste à faire, ordonnée par valeur, jamais figée.
• Des boucles de feedback courtes : montrer tôt, ajuster.
• La rétrospective : s'arrêter régulièrement pour améliorer sa façon de travailler.
• Rendre le travail visible : un tableau, quel que soit le métier.

Ce qui demande à être adapté

Le vocabulaire (« incrément livrable » n'a pas le même sens pour une campagne de communication que pour du code), la notion de « fait » (les critères d'acceptation), et le rythme (un sprint de deux semaines n'est pas toujours la bonne maille).

Des exemples hors informatique

• Marketing : une campagne construite par vagues, testée sur un petit segment avant d'être généralisée ; un backlog de contenus priorisé.
• Ressources humaines : un nouveau processus de recrutement testé sur un poste, ajusté, puis étendu.
• Événementiel : un événement préparé par jalons, avec des points de décision go / no-go, et une rétrospective après chaque édition.
• Recherche et développement : des expériences courtes avec une hypothèse claire, comme la boucle construire-mesurer-apprendre.

La limite

Là où le besoin est parfaitement connu et stable, ou là où l'on ne peut pas livrer par morceaux, l'approche classique reste préférable — comme pour un projet informatique (voir la leçon « quand l'agile n'est pas le bon choix »).

Exemple concret : l'équipe marketing qui promeut l'application de fidélité travaille en sprints de deux semaines : un backlog de contenus et d'actions priorisé par la responsable marketing, une revue tous les quinze jours pour regarder ce qui a fonctionné, une rétrospective pour ajuster la méthode.

À vous de jouer : citez un domaine hors informatique et une pratique agile qui s'y appliquerait bien.