Validité de l’opportunité, faisabilité, programmation, budget… Le quotidien d’un MOA est de s’assurer formellement que le service ou produit développé correspond aux spécifications des besoins fonctionnels des Métiers. Communiquant hors pair, Jérémy est, sur le terrain, un créateur de valeur ! Son seul objectif, la satisfaction des utilisateurs. Ancien développeur, ancien assistant trader, c’est son parcours à mi-chemin entre la technique et l’utilisateur qui l’a naturellement conduit à endosser le rôle de MOA. Mais attention pour être MOA « il faut le vouloir et avoir une vraie appétence à communiquer avec les personnes qui nous entourent ». Entretien.
Vous êtes MOA dans une grande banque française, en quoi consiste votre métier ?
Au quotidien, je suis le lien entre les développeurs et les utilisateurs, je dois donc parler les deux langages, c’est pourquoi je compare volontiers mon métier à celui de traducteur. Chaque sphère a ses propres codes, sa propre façon de penser.
Les développeurs cherchent la complexité, là où les utilisateurs cherchent de la simplicité ! C’est pourquoi ma mission consiste d’une part, à faire comprendre à l’utilisateur qu’il faut parfois aller vers des développements complexes s’il veut de nouvelles fonctionnalités ou à contrario moins complexes pour des questions de coûts.
Et d’autre part, je dois expliquer aux développeurs que la complexité n’est pas un objectif en soi et que la priorité est de rendre une application user friendly. C’est à dire facile d’utilisation, jolie à regarder et rapide à prendre en main.
À quel moment décide t-on de devenir MOA ?
Mon cas est un peu particulier. En début de carrière, j’étais un développeur « commando » c’est à dire un développeur très proche des utilisateurs. Mon objectif était de faire du développement rapide, c’est à dire, qu’entre l’expression du besoin et la livraison, il ne se passait que quelques jours, voire dans certains cas, seulement quelques heures.
J’avais alors un rôle transverse, à la fois de développeur, de business analyst et à la fois de support, puisque je devais expliquer à l’utilisateur comment fonctionnait l’application, une fois développée. Ce rôle correspondrait aujourd’hui à la démarche DevOps, dans laquelle le développeur communique directement avec l’opérationnel.
Par la suite, tout en continuant à faire du développement, j’ai très vite endossé un rôle de chef de projet avec de nombreux développeurs à manager. Ce sont ces différents rôles qui m’ont donné envie de devenir MOA.
Tout développeur peut-il devenir MOA ?
La première chose c’est qu’il faut le vouloir ! De nombreux développeurs sont des loups solitaires, qui ne communiquent que très peu avec leur entourage. Et, être MOA, c’est avant tout avoir une vraie appétence à communiquer avec les personnes qui nous entourent, être capable d’aller discuter des méthodes de travail avec chaque membre de l’équipe.
Quelles sont les qualités d’un bon MOA ?
Il faut posséder de grandes capacités de communicant. Le sens du relationnel et l’empathie vont permettre d’instaurer très vite un bon dialogue avec toutes les parties prenantes. Avoir des capacités fonctionnelles ou techniques est un plus mais je ne pense pas que ce soit des pré-requis.
Le MOA a un rôle clé dans l’organisation de l’entreprise. Il est responsable de la bonne relation entre les différentes directions (Métier, informatique). À quelles réticences êtes-vous confronté au quotidien ?
Du côté des développeurs, je suis confronté à deux profils différents. Le premier profil est celui du développeur passionné, pour lequel la complexité du code est un challenge. Il va « challenger » le MOA sur la performance du produit. Ce développeur, il faut le freiner pour des raisons de coûts évidentes.
Le second profil est celui du développeur opportuniste, qui fait du code parce qu’aujourd’hui c’est un métier assez bien rémunéré. Son fonctionnement est simple : il prend des bouts de code existants, change deux trois lignes, pour aller les implémenter dans la nouvelle application. Il sera incapable de créer de nouvelles fonctionnalités. Plus qu’une réticence, on peut appeler cela une limite.
Côté Métiers, comme je suis tourné utilisateur, les réticences sont donc rares. D’autant plus que je préfère challenger les développeurs que les utilisateurs.
MOA, une bonne transition vers les métiers ?
D’une certaine façon oui. On peut créer des passerelles en provoquant des opportunités. Toutefois, et cela n’engage que mon expérience, un MOA risque de vite déchanter ! Ce qui est sympa avec notre métier de MOA c’est qu’on est tout le temps sur de nouvelles choses alors que du côté des métiers, on exécute souvent des tâches répétitives. Quand on est MOA, on pense que tout change tout le temps or ce n’est pas le cas chez les Métiers. Quand j’étais assistant trader, pendant deux ans, j’ai fait tous les jours la même chose.
Qu’est ce qu’un développeur peut apporter à un MOA ? Et inversement ?
Le développeur va apporter la partie technique à un MOA et également la capacité d’évaluer un coût de développement. Et inversement, le développeur va apprendre du MOA tout ce qui concerne la partie fonctionnelle, au sens de user expérience. Chaque partie gagne en compétences, le développeur va ainsi comprendre les enjeux utilisateur comme l’ergonomie ou les usages, et le MOA va renforcer sa culture technique et apprendre très vite à identifier ce qui est techniquement possible de faire ou pas.
Sur le terrain, comment assurez-vous la bonne adéquation entre la stratégie « Métier » et son système d’information ?
L’une des plus grandes contraintes sur le terrain, c’est l’existant ! Car rarement un MOA est confronté au développement d’une nouvelle application. On est le plus souvent confronté à une application déjà existante qu’il faut triturer dans tous les sens pour l’améliorer et qu’elle corresponde aux besoins métiers. Nous avons des contraintes legacy, de lourdeur de code qui nous obligent à nous adapter.
On fait plus de l’innovation incrémentale que de l’innovation de rupture. Aujourd’hui, les grandes organisations décommissionnent des logiciels pour les refaire à l’identique. Ce qui change c’est simplement le modèle. On va utiliser, par exemple, un langage objet à la place d’un langage de données car plus évolutif, plus facile à maintenir ou encore à livrer.
Faire de l’innovation de rupture est très compliqué car on se retrouve parfois dans des organisations qui comptent, dans leur architecture, plus de 1000 applications dont beaucoup sont interdépendantes. Nous sommes donc obligés de faire des ruptures partielles pour que les applications s’adaptent. L’innovation de rupture peut se faire dans des petites structures qui n’utilisent que très peu de logiciels. Elles seules, ont les moyens de faire un big bang.
Dans les grandes organisations, tous les projets sur lesquels j’ai travaillé et qui visaient à transposer des parties dans une nouvelle application ont soit été arrêtés, soit sont toujours en cours mais aucun n’enregistre 100% d’achèvement.
Quelle est justement pour une entreprise la valeur ajoutée d’un système d’information aligné sur une stratégie Métier ?
Être aligné permet de gagner du temps car qui dit du temps machine dit du temps utilisateur. Qui dit temps utilisateur dit nécessité de recruter de nouveaux collaborateurs et donc une masse salariale qui augmente… et forcément en bout de chaîne, des coûts ! Avoir un système d’information aligné sur les besoins fonctionnels va permettre de faire gagner du temps et donc de l’argent !
