Mes compétences exploitées dans le BTP

Mon Client voulait mettre en place un outil pour ses chefs de chantier avec des objectifs prédéfinis :

  • Avoir une fonctionnalité d’imputation des heures
  • Pouvoir accéder à tous les éléments du dossier composant le chantier (plans, déclarations de travaux, devis, photos de lieux, etc.)
  • Pouvoir réaliser des commandes d’appoint en interne (petit matériel)

Mon rôle était de l’assister dans sa démarche en transposant les besoins en une application tablette. De la définition des fonctionnalités à l’architecture cible. Nous avons lancé une série d’ateliers et d’entretiens individuels pour recueillir l’ensemble des besoins.

Imputer des heures doit se faire facilement pour le chef d’équipe, il ne doit pas répéter x fois la même chose pour dire qu’un de ses ouvriers a fait de la peinture toute la semaine. L’enjeu était d’autant plus important que tout cela devait se faire uniquement au travers d’une tablette. Il fallait tout faire au doigt et dans le BTP, on parle de « gros doigts », donc une interface ample et épurée, qui soit le plus facile d’accès possible. Côté back-office, ce pointage des heures devait permettre au service RH et au service comptable de gérer facilement les feuilles de salaire. Il fallait notamment tenir compte des congés, des jours fériés, etc. En disant cela, vous comprenez que les chefs d’équipe n’étaient pas les seuls acteurs de cette future application, nous avions dès le départ 8 rôles différents à gérer.

Pour le dossier travaux, il fallait gérer des droits d’accès entre le chef d’équipe et le conducteur de travaux (le chef des chefs d’équipe) mais aussi plus globalement pouvoir réattribuer un chantier à un autre chef d’équipe (remplacement).

La commande devait pouvoir se faire toujours depuis une tablette, il fallait jongler entre des commandes poussées par le conducteur de travaux et par le chef d’équipe. Surtout, nous ne voulions pas submerger le responsable de l’entrepôt, recevoir plusieurs commandes par jour d’un même chantier multiplié par une centaine de chantier était impossible. Nous avons donc mis en place un système de ramassage, la commande est devenue un panier qui chaque jour était transformé en une commande en milieu de journée. L’horaire n’était pas choisi au hasard, cela devait être suffisamment tard pour éviter des frustrations sur le chantier (je n’ai pas eu le temps d’ajouter du scotch à mon panier) et suffisamment tôt pour que l’entrepôt ait préparé la commande pour le lendemain. Le conducteur de travaux quant à lui pouvait compléter une commande même dans l’après-midi en cas d’urgence.

Pour en arriver là, chaque recueil donnait lieu à un compte-rendu et des maquettes graphiques afin de pouvoir se projeter dans la réalisation. Le compte-rendu était progressivement transformé en spécifications fonctionnelles et techniques, en résumé, un gros travail d’AMOA avec une méthodologie bien précise.

La mise en perspective de l’outil a soulevé de nombreuses questions et a permis d’étoffer considérablement le périmètre des fonctionnalités. Les commandes d’appoint sont devenues un véritable outil e-commerce dans la deuxième version de l’application avec la possibilité de commander des matériaux plus volumineux dont des éléments entiers d’échafaudage.

Rapidement, l’application est devenue un puits sans fond de besoins. Avant même la prise en main de la première version, nous avions une longue liste de fonctionnalités à ajouter. L’important dans cette situation est de savoir s’arrêter, boucler le périmètre, sinon vous pouvez vous retrouver des années plus tard sans avoir jamais confronté l’outil à ses utilisateurs et faire un bide.

L’outil a été développé dans une V1 et une phase de formation et de conduite de changement a été mise en place. Pour une partie des chefs de chantier, c’était la première fois qu’ils utilisaient une tablette en dehors d’un rayon de magasin. Cela a duré plusieurs mois durant lesquels nous avons accumulé un grand nombre de retours d’expérience. Ces derniers, peu importe leur nature, étaient répertoriés. Cumulé à la liste créée avant la mise en production, nous avons pu définir une roadmap de trois versions, ici la V2, la V3 et la Vx. Cette dernière est le pot commun de tout ce que nous ne pouvions pas mettre dans la V2 et V3.

Le fait que l’application se retrouve sur le terrain a permis une autre forme d’atelier, nous avons pu faire des immersions sur chantier pour observer comment l’outil était utilisé. Ce qui a apporté de nombreuses petites évolutions qui étaient réalisées dans le cadre d’un contrat de maintenance (TMA). Pour le reste, c’est un éternel recommencement : atelier, maquette, spécifications fonctionnelles et techniques, réalisation, formation, conduite du changement, retours d’expérience, amélioration, atelier, maquette… Juste un détail, je risque de vous le dire plusieurs fois, il y a du marketing partout et dans le cadre de ce projet. L’application est devenue un projet SaaS avec le souhait de pouvoir le commercialiser auprès des autres entreprises du BTP. Ce qui était un investissement au départ va devenir une rente.