Dans une entreprise de suivi de travaux, on nous a demandé un audit après deux ans d'utilisation d'Asana. Le constat de la direction tenait en une phrase : ça ne sert pas à grand-chose. Ce que nous avons trouvé n'était pourtant pas un outil vide. Il était plein.
Plein de projets créés selon cinq logiques différentes. Un conducteur de travaux avait fait un projet par chantier, un autre un projet par client, un troisième un projet par année. Certains suivaient des lots, d'autres des tâches, d'autres encore des comptes rendus de réunion.
Chacun avait construit quelque chose de cohérent. Aucun ne pouvait lire celui du voisin. Personne n'avait refusé l'outil. Personne ne l'avait cadré.
Le problème spécifique : dans le bâtiment, l'échec d'adoption prend rarement la forme d'un rejet
On imagine souvent l'adoption ratée comme un blocage frontal : les équipes qui refusent, le terrain qui résiste. Dans le BTP, nous observons plus souvent l'inverse.
Un conducteur de travaux est autonome par métier. Il gère son affaire, il arbitre, il improvise quand la météo décale un lot. Donnez-lui un outil sans mode d'emploi, il ne le rejettera pas : il l'adaptera à sa façon de travailler.
Multipliez par cinq conducteurs, et vous obtenez cinq systèmes parallèles hébergés dans le même logiciel.
C'est un échec d'adoption particulier, parce qu'il ne se voit pas dans les statistiques d'usage. Les licences sont utilisées. Les projets vivent. Et pourtant la direction ne peut consolider aucune information, parce que rien n'est comparable.
Le second symptôme du secteur est plus classique, et il aggrave le premier : la dépendance aux personnes.
Nous l'avons rencontré dans une entreprise de travaux et d'aménagement de bureaux, où le suivi réel se répartissait entre des post-its, des boîtes mail partagées et des documents personnels. Un outil de gestion de projet y avait été déployé, puis utilisé par obligation, sans adhésion réelle. Chaque absence emportait l'information avec la personne.
L'objectif que la direction a fini par formuler résume tout le sujet : que l'avancement d'un chantier ne dépende plus jamais d'une seule personne.
Le Work Trend Index 2025 de Microsoft situe la répartition du temps de travail autour de 57 % consacrés à communiquer contre 43 % à produire. Dans le bâtiment, cette communication prend la forme d'appels pour reconstituer une information qui existe déjà quelque part.
Pourquoi Asana peut répondre — à condition d'être cadré
Asana ne manque pas de fonctionnalités. Il manque presque toujours de convention.
Ce que l'outil apporte au bâtiment est réel. Une tâche porte un responsable qui est une vraie personne, une échéance, et se retrouve automatiquement dans l'espace personnel de celui qui doit la traiter, tous chantiers confondus. Un conducteur voit sa journée sans ouvrir cinq projets.
Les modèles de projet permettent de figer une trame de chantier commune : phases, points de contrôle, réception. C'est la façon la plus efficace d'imposer un cadre sans avoir à le rappeler — le cadre arrive avec le projet.
Et au-dessus, une lecture consolidée du portefeuille de chantiers devient possible, précisément parce que tous les projets partagent la même structure.
Mais rien de tout cela ne fonctionne si les questions de fond n'ont pas été tranchées.
Qu'est-ce qu'un projet chez vous : un chantier, une affaire, une phase ? À quel moment un chantier est-il « livré » ? Qui a le droit de clore une réserve ?
Ces réponses ne sont pas dans le logiciel. Elles sont dans votre organisation, et tant qu'elles ne sont écrites nulle part, chacun continuera d'inventer les siennes.
Notre recommandation de configuration
- Trancher la maille avant tout paramétrage.Un projet = un chantier, une tâche = une action, une section = une phase. Une seule règle, écrite, valable pour tout le monde. C'est la décision qui conditionne toutes les autres, et c'est celle qu'on saute le plus souvent.
- Une trame de chantier unique, déployée par modèle.Les phases, les points de contrôle, les jalons de réception. Un conducteur qui démarre une affaire ne construit plus sa structure : il la reçoit. C'est ainsi qu'un cadre s'impose sans note de service.
- Écrire ce que « terminé » veut dire, phase par phase.Tant que la fin d'un lot signifie trois choses différentes selon les personnes, aucun indicateur d'avancement n'est fiable, et aucun tableau de bord ne mérite d'être construit.
- Un responsable unique et une date sur chaque élément.Quand il y a plus d'un responsable, il n'y a plus de responsable. Et une action sans date passe systématiquement derrière celles qui en ont une : sur un chantier, elle refait surface au moment de la réception.
- Auditer l'existant avant de reparamétrer.Si l'outil tourne depuis un ou deux ans, il contient des pratiques utiles inventées par les équipes. On les identifie, on garde les meilleures, on abandonne le reste. Repartir d'une page blanche est le meilleur moyen de perdre les gens qui s'étaient investis.
- Désigner des référents par agence ou par périmètre.Une ou deux personnes formées un cran plus loin, qui répondent aux questions du quotidien et font remonter les bonnes pratiques. C'est ce qui rend l'entreprise autonome après notre départ.
Comment on a accompagné ce type d'entreprise
Sur l'entreprise de suivi de travaux évoquée en ouverture, la mission a été volontairement courte.
Un audit de l'utilisation existante d'Asana, chantier par chantier et conducteur par conducteur. Une analyse des pratiques et des difficultés réelles. Puis des recommandations, et surtout un plan d'action détaillé.
Le livrable central n'était pas un nouveau paramétrage. C'était un cadre : quelle maille, quelle nomenclature, quels statuts, quelles règles communes.
Nous aurions pu reconstruire l'espace. Cela aurait été plus spectaculaire, et probablement moins efficace : l'outil n'était pas le problème.
Sur l'entreprise de travaux et d'aménagement de bureaux, la situation était différente. Un outil de gestion de projet y avait déjà échoué faute d'adhésion, et il fallait repartir du besoin plutôt que du logiciel.
Nous avons complété un kit de structuration pour comprendre les processus et les interactions réelles, en englobant tout ce que la direction n'avait pas mis dans le périmètre initial : les tâches administratives, les affaires, les chantiers, les demandes de dépannage et les petits chantiers.
Trois scénarios d'outillage ont été proposés, puis l'espace retenu a été construit et implémenté.
Un outil n'échoue presque jamais tout seul. Il échoue quand on lui demande de remplacer une décision d'organisation que personne n'a voulu prendre.
Ce qu'en disent les clients
Ce témoignage vient d'un autre secteur ; le levier, lui, est identique :
« Quotid'up nous a brillamment accompagnés pour challenger nos process internes et organiser notre Asana en cohérence. L'équipe a su profiter de l'arrivée d'un directeur de pôle pour mettre à plat l'usage d'Asana, ré-onboarder tout le monde et faire de cet outil très puissant un succès. »
FAQ — Adoption d'Asana dans le BTP et la construction
Nous utilisons Asana depuis deux ans sans que ça prenne. Faut-il changer d'outil ?
Presque jamais. Changer d'outil sans changer le cadre reproduit le même résultat quelques mois plus tard, avec le coût de la bascule en plus. Commencez par un audit des pratiques réelles : dans la grande majorité des cas, il faut poser des règles, pas racheter des licences.
Chaque conducteur de travaux organise ses projets à sa manière. Comment harmoniser sans braquer ?
En regardant d'abord ce que chacun a construit. Il y a toujours de bonnes idées dans ces systèmes parallèles, et les reconnaître change complètement la réception du cadre commun. On construit la trame unique à partir de ce qui existe, pas contre.
Comment faire remonter l'information depuis le chantier sans alourdir le terrain ?
En réduisant le geste au minimum. Un formulaire court accessible depuis un téléphone, quelques champs, aucune navigation. Le terrain ne doit pas avoir à entrer dans l'outil pour y contribuer, et le bureau ne doit pas avoir à le rappeler.
Faut-il un projet Asana par chantier ?
C'est la maille la plus courante et généralement la plus lisible, avec une section par phase. Mais l'important n'est pas la réponse : c'est que la réponse soit la même pour tout le monde et qu'elle soit écrite quelque part.
Combien de temps prend une remise à plat de ce type ?
Un audit court se compte en semaines et produit un plan d'action exploitable. L'ancrage des nouvelles règles, lui, se compte en mois — avec des points de contrôle après la mise en service, parce que les vraies difficultés apparaissent quand un chantier tendu remet la pression sur les équipes.
Voir aussi
Votre outil est plein, et pourtant rien ne se consolide ?
Regardons ce que chacun y a construit, et ce qui manque comme règle commune. Quelques questions, moins de 10 minutes.
Réserver un diagnostic gratuit- Monday Partner
- Asana Partner
- Notion Advanced
- AirSaas