Connected to the future - ITnation

«Arηs permet de bouger d’un projet à l’autre,
on croise beaucoup de monde, on s’essaye
à plein de technologies. BSB a commencé
en 1997-98, alors que les frameworks
genre Hibernate et Spring n’existaient pas
encore.». Dès son arrivée chez Arηs, il
s’attelle au projet DOOR pour la DG Agriculture
de la Commission Européenne. La
Database Of Origin and Registration doit
compiler les informations sur les produits
bénéficiant d’une Appellation d’Origine
Protégée, Indication Géographique Protégée
ou une Spécialité Traditionnelle Garantie
qui circulent dans l’UE mais aussi dans le
monde (par exemple, il y a une AOP pour
le ‘Café de Colombia’). Un projet de taille.
«Là, j’ai pratiquement tout fait : architecture,
développement technologique, schéma de
la database Oracle. J’utilisais Hibernate
pour la persistance et Spring pour toutes
les autres couches.» Il participe ainsi au
développement, au test, au packaging et à
la démo. «La perception des utilisateurs est
parfois vachement différente, il ne faut pas
nécessairement rester simple au niveau des
couleurs, par exemple.»
À L’ÉCOUTE
Le projet a été livré en octobre 2008. Avant
cela, Mathieu travaillait déjà en partie sur
d’autres projets, notamment pour d’autres
départements de la ‘DG Agri’ et particulièrement
sur le projet ISAMM, un prototype de
template management pour la création de
formulaires envoyés aux Etats Membres. «Il
faut pouvoir laisser la liberté à l’utilisateur de
créer son formulaire dynamiquement», tout
en incluant des fonctions de calcul, telle que
la somme automatique de produits importés.
«Même si les projets demandent d’utiliser
des technologies relativement proches, il y
a toujours des différences qui font qu’on
s’amuse», confie-t-il. Dans le cas d’ISAMM,
l’application a été conçue par d’autres membres
de l’équipe d’Arηs.
Mais rien n’est jamais figé. Non seulement le
chef de projet rencontre le représentant des
utilisateurs, mais la DG elle-même sollicite
les Etats membres pour suggérer des améliorations.
Dans le cas de DOOR, l’analyse
fonctionnelle et les premières ébauches du
prototype ont duré six mois avant d’entamer
le développement réel de l’application. «Il
faut prendre le temps de bien comprendre
le business du client et de préparer l’architecture
en conséquence.» Et dans ce cas, le
rôle du développeur en amont est aussi de
demander des explications au client. «Pour
tester correctement l’application, il faut
savoir ce qu’elle est sensée faire,
et pour cela, comprendre la partie
fonctionnelle du client. Il faut aussi
penser aux extensions, prévoir que
le client va demander des modules
complémentaires. Les clients veulent
aussi innover.» En tant que
développeur, Mathieu dispose
de plus ou moins de liberté en
fonction des exigences des
clients. «Certains veulent certains
types de technologies,
des rendus graphiques précis,
etc. On n’a alors pas
trop le choix. Par contre, si
le client se concentre sur
ses besoins, c’est plus
drôle pour nous. On peut
faire ce qu’on veut avec
ce qu’on maîtrise. En cas
de problème, on assure la
maintenance donc on sera
responsable.»
© Photography Raoul Somers