Comment aborder FileMaker ? (2)

La semaine dernière, je vous expliquais qu’on n’abordait pas FileMaker comme un quelconque logiciel dont il suffit de connaître et comprendre les menus pour savoir l’utiliser.

Car derrière FileMaker, se cachent quatre « métiers » ou « casquettes » : analyste, développeur, utilisateur et administrateur…

À chacune correspondent des formations bien spécifiques.

Pour l’analyste, muni de son papier et de son crayon, la connaissance de FileMaker lui est peu utile, sinon pour retraduire partiellement en FileMaker ce que son analyse a déterminé notamment au niveau de la structure. Cette « traduction » est en fait le point de jonction entre le rôle de l’analyste et celui du développeur qui prend le relais.

Le développeur est clairement celui qui doit avoir la connaissance la plus approfondie et la plus étendue de FileMaker. Mais son point de vue ne doit pas être uniquement « technique » : il est aussi méthodologique et ergonomique. Il doit avoir suffisamment de recul pour adopter telle approche plutôt que telle autre lorsqu’il en existe plusieurs pour effectuer la même tâche. Et il doit aussi penser à ce qui sera le plus cohérent et le plus confortable possible en termes d’interface utilisateur.

L’utilisateur est celui à qui une visite détaillée des menus de FileMaker – en dehors de ceux servant à la conception d’une base – et des boutons est la plus utile. Sa formation, qui vise la bonne prise en main de la base, comporte deux aspects : les menus de FileMaker, communs à toutes les bases, et les boutons ou actions propres à la base qu’il utilise. De ce point de vue, si l’interface utilisateur a été conçue de manière suffisamment intuitive, la formation à l’utilisation de la base se réduit à pas grand chose. En méthode agile, elle est même incluse naturellement aux différentes phases de développement.

Enfin, l’administrateur possède une formation suffisamment transversale pour paramétrer FileMaker et FileMaker Server, mais aussi pour gérer tout l’environnement dans lequel ces logiciels vont évoluer.

Lorsque c’est une seule et même personne qui assume ces différents rôles, comme c’est fréquemment le cas, la difficulté est de bien les distinguer pour que les étapes du travail notamment soient bien claires : l’étape analyse n’est pas la même chose que l’étape développement. Il faut que la personne – ici personne-ressource – en soit bien consciente et que ceci soit perçu par l’équipe pour laquelle elle travaille. La difficulté peut être en outre accrue par la méthode agile, qui, pour chaque « module » à fournir, reprend successivement toutes les étapes.

En revanche, lorsqu’une seule et même personne assure l’analyse, le développement et l’administration, on bénéficie d’une plus grande souplesse et réactivité d’intervention. On gagne – peut-être en partie illusoirement – sur le temps de coordination entre les différents intervenants.

Il est préférable de séparer ces quatre grands rôles, notamment dans les grands projets. Mais même pour ceux de taille relativement modeste, un regard différencié peut être bienvenu : le point de vue de l’analyste n’est pas celui du développeur. Travailler à plusieurs sur un même projet permet de prendre du recul, de trouve des solutions sur les éventuels points de blocage, ou encore, des idées originales et créatives pour tel ou tel aspect du projet… Mais attention, au final, quelle que soit la casquette revêtue, la destination de tout ceci est le travail de l’utilisateur dans la convivialité et l’efficacité.

Alors ?

Alors, la réussite d’un projet est le fruit d’une mystérieuse alchimie, de qualités humaines (empathie, écoute, capacités d’analyse…), de compétences et de bon sens…

Et aussi, la nécessité de ne pas rester seul…

Marie-Charlotte Potton

Article précédent

Tags: Se former à FileMaker