Jean-Christophe Régnier, Directeur Consulting de Petals Link, présente la ligne directrice de Petals pour 2012 : une branche mieux définie (Petals 4), une expertise sur mesure, et une nouvelle offre de support.
Laurent Lacôte : Bonjour Jean-Christophe, merci de nous accorder cette interview. Pour commencer, pourrais-tu nous résumer ton parcours ?
Jean-Christophe Régnier : Bonjour. Ma carrière a commencé chez Transiciel, une SSII rachetée depuis par Sogeti. Je devais y définir les spécifications de composants logiciels d'un simulateur de plate-forme aéroportuaire, et les réaliser. J'ai ensuite réalisé des projets d'architectures chez plusieurs clients successifs : Renault, JC Decaux, Thalès, Éducation Nationale... Beaucoup étaient orientées services, en lien avec la popularité croissante de la SOA. Mes missions ont donc inclus la mise en place d'ESB, la conception de l'architecture, le pilotage d'équipe etc.
Laurent : Tu connais donc l'offre logicielle sur le marché de l'ESB ?
JC : Disons que j'en ai un bon aperçu, j'ai principalement utilisé les solutions Websphere d'IBM, également Fuse ESB, et enfin Petals ESB.
Et comment, pour toi, se place Petals ESB par rapport aux autres ?
Pour moi sa grande force est sa conception, qui propose beaucoup de fonctionnalités essentielles, et surtout permet des types d'architecture que d'autres ne proposent pas, notamment une architecture distribuée.
De plus, son respect du standard JBI en fait un middleware modulaire, très flexible. On peut créer n'importe quel composant pour s'adapter à un système legacy, à des besoins spécifiques d'exécution ou d'intégration de technologies. Ça permet de proposer des solutions sur mesure pour les clients, parfois en avance de phase par rapport à la roadmap de développement du produit.
Est-ce pour ça que tu es venu chez Petals ? L'intérêt technique ?
Je voulais surtout profiter de l'opportunité : monter une structure sur Paris, être responsable de A à Z sur une agence et développer mes compétences sur les plans à la fois commercial et technique, c'est passionnant. Et nécessaire. Pour présenter un produit technologique comme notre ESB, il faut connaître techniquement le produit pour le présenter de manière claire et carrée, car nombre de concepts sont à l’œuvre. Il faut savoir pourquoi le produit existe, quelles sont les valeurs ajoutées, comprendre les besoins des clients et y répondre, éviter de vendre du vent, pour établir une relation de confiance. Petals est une structure encore jeune, réactive, vouée à se développer commercialement, et je suis heureux d'avoir la chance d'y participer !
La structure sur Paris a été lancée au printemps dernier. Où en êtes-vous, quelles sont tes priorités, tes perspectives pour les mois à venir ?
Le bureau de Paris est principalement axé sur les missions consulting et commerciales. Nous avons déjà embauché un consultant, et nous planifions une autre embauche, en réponse aux nouveaux contrats clients.
L'objectif est d'avoir une intégration progressive et maîtrisée, quelqu'un qui rentre à chaque trimestre en corrélation avec les nouveaux projets. Durant une de mes anciennes missions, l'éditeur du cœur logiciel n'avait pu s'impliquer autant que nous le voulions. D'où quelques erreurs et retard de par notre manque de connaissance du produit. Je veux éviter que nos clients retrouvent cette situation.
Ma vision est d'axer sur du service "de proximité". Proposer du sur-mesure, tout en évitant les promesses irréalisables. Bref, avoir une croissance maîtrisée. Par exemple, j'ai évoqué la possibilité de développer des composants indépendamment du développement produit. Nous sommes en train de créer, au niveau consulting, deux composants qui vont arriver sur la version 3 de Petals.
Le premier assure la persistance des messages et l'invocation des services, c'est-à-dire l'exécution d'un service de manière sécurisée : lorsqu'un client appelle un service au travers du bus, on lui garantit que ce service sera exécuté à un moment ou à un autre. Ceci avec une politique de reprise automatique/manuelle et un système d'alertes. On gère la persistance en passant d'un appel synchrone à un appel asynchrone, grâce à un gestionnaire de file d'attente.
Le deuxième composant, c'est CAMEL, pour Apache CAMEL, bien connu et utilisé par pas mal de monde, et qui va permettre de supporter un plus grand nombre de patterns d'EIP.
Voilà deux nouveautés sur la base de Petals 3 qui permettent au client d'avoir des fonctionnalités supplémentaires en avance de phase avant qu'elles soient intégrées dans la prochaine version majeure en cours de développement, Petals 4.
Que va amener cette nouvelle version, Petals 4.0 ? Pourquoi pas une 3.2 ?
Cette version 4.0, prévue pour début 2012, symbolise l'adoption d'une politique de qualité plus robuste, s'appuyant sur plus de tests d'intégration continue et l'adoption de la méthodologie de développement SCRUM. Cela ne garantit pas en soi la qualité, mais nous permet de mieux définir et superviser les objectifs, la qualification, la recette. Au prix d'un périmètre fonctionnel plus restreint, on a une bien meilleure maîtrise de la qualité de la version stable. Ça ne peut qu'être bénéfique sur le long terme. Par exemple, la fonctionnalité majeure de la 4.0 sera une réponse professionnelle aux problématiques de supervision métier, supervision des flux, c'est un objectif important. Par ailleurs, elle servira de base à la première édition "Entreprise" de Petals.
D'accord, et quand tu parles de la 4.0 comme la première version Entreprise, qu'apporte-t-elle ?
L'arrivée d'une édition "Entreprise" de Petals correspond à l'arrivée d'une nouvelle offre de support. Nous proposerons un service à très forte valeur ajoutée, car portant sur une version bien testée, sur un périmètre réduit et un code maîtrisé. Car rappelons-le, la plupart des contributeurs au code sont (ou ont été) chez nous.
Tous les détails ne sont pas encore arrêtés. Nous garderons une offre différenciée selon que le projet est en développement ou en production.
Pour le support en Production, nous proposerons des tarifs dégressifs en fonction du nombre d'instances, par paliers (5, 10, 20...), car la force de Petals est d'être nativement distribué. Sachant que des clients comme l'ACOSS ont déjà déployé plus de 20 instances. Nous voulons vraiment favoriser les déploiements à large échelle.
Quant au support en Développement, aujourd'hui basé sur un nombre de tickets et d'heures alloué, nous le modifierons en proposant des pool de jours de consultant, durant lesquels il se tiendra à disposition du client.
L'idée est que le client profite de notre expertise aux moments forts du projet, notamment au début - lui donner un coup de boost. Cela facilitera également le support au long cours, grâce à la relation privilégiée entre le client, son projet, et le consultant Petals.
Pour terminer, peux-tu nous parler de projets clients en cours ou en production, ou c'est confidentiel encore ?
Certains le sont, pas tous. J'ai envie de citer le projet de la Région Aquitaine, très intéressant de par son mode de déploiement, qu'on pourra retrouver ailleurs. Son objectif est de fournir un portail de services pour les citoyens. Cela implique des contraintes de disponibilité fortes (24h/24, 7j/7), paradoxalement aux contraintes horaires du personnel administratif de la Région.
L'idée est donc de faire héberger le portail, en même temps qu'une instance de Petals, chez un hébergeur qui puisse tenir des conditions de disponibilité. L'instance de Petals assurera la transmission de tous les messages du portail, vers le back-office hébergé en local chez le Conseil Régional, lui aussi épaulé par une instance Petals. Les deux instances Petals, avec l'aide également du nouveau composant évoqué plus haut, assureront ainsi le traitement des requêtes sans nécessiter de développement spécifiques ni au niveau du portail ni au niveau du back-office.
Nous sommes d'ailleurs sur ce projet en partenariat avec Genitech, qui propose une solution métier nommée e-Citiz de services aux citoyens. Nous on fournit l'infrastructure de téléservices, eux font le portail de téléservices.
Cela fait partie de nos pistes de croissance, une politique de partenariats. D'abord avec des éditeurs de solutions métiers (administration, santé, logistique,...) ou de solutions techniques, comme nous l'avions fait avec Talend, et comme nous faisons actuellement avec le composant Apache Camel.
Ensuite avec les intégrateurs : notre vocation n'est pas de gérer la maîtrise d’œuvre sur des gros déploiements, mais d'apporter notre expertise tout au long du projet. Notamment en évitant de "mauvaises" utilisations du produit qui causeraient des problèmes inutiles à l'intégration et au déploiement.
Parfait, plein de choses en perspective donc. Merci pour cette interview !
Merci à toi, au revoir !
