Développements de Kondor+ 3.0 Pilotage de 70 ingénieurs pour un projet stratégique Kondor+, une application financière de gestion des transactions réalisées des salles de marchés, représente le cœur de l offre de l'activé «Trade & Risk Management» de la société Reuters. Kondor+ est le logiciel leader dans son secteur avec un CA de 90 millions d euros, environ 650 clients et 13 000 utilisateurs dans le monde. Après 9 versions livrées entre 1994 et 2003, Reuters décide de donner une nouvelle dynamique à Kondor+ en sortant la version 3.0. prévue pour 2006, avec des améliorations marquantes, fonctionnelles, nouveau module de repos, nouveaux rapports de positions en temps réel et techniques, déploiement de la même application sur plusieurs sites partageant les mêmes données. J'ai lancé en 2003 une étude de faisabilité qui a permis de : - valider les changements technologiques à intégrer : nouvelle interface graphique, moteur de webservice C++ pour le passage en une «architecture orientée services» - estimer l'investissement pour ce projet, l'un des plus gros réalisés chez Reuters : 30 000 jours/hommes dont 12 000 jours/homme pour la partie «codage». - identifier les besoins humains : profils, nombre de personnes. Nous avons recruté en 2004 une vingtaine de collaborateurs dont celui de 5 chefs de projets qui a marqué un important changement culturel, par rapport à une culture de promotions internes. En février 2005, j ai mis en place une nouvelle organisation pour Kondor+ et sa suite logicielle incluant jusqu à 70 ingénieurs de développement pour la version 3.0.. Kondor+ 3.0 est sortie en avant première en décembre 2005 pour la banque néerlandaise ING, un de nos plus gros clients. La sortie «bêta» réalisée à la date prévue, fin mars 2006, a été mise en test chez 4 clients. Version très bien accueillie lors d un «test bed» organisé en juin 2006, avec présentation à une douzaine de clients qui ont apprécié les innovations, la stabilité et la qualité rarement atteinte à ce stade pour un projet de cette taille. Kondor+ 3.0 est en production depuis le mois d août 2006 dans la banque Calyon à New York et officiellement mise à la vente avec un succès certain depuis le mois de septembre comme peuvent en témoigner la signature des contrats ING et Calyon en 2005 et les 26 nouveaux clients acquis en 2006 dont Mistubishi Securities Co. Ltd au Japon, Barclays en Espagne ou le groupe Total en France. 1
Fusion réussie d'effix et Diagram Valorisation des compétences et création de produits En mars 2001 Reuters acquiert la société Diagram pour compléter son produit "Front Office" Kondor+ par un produit "back office" DCM (Diagram Capital Market). et décide de fusionner les équipes de production Diagram, environ 100 personnes avec celles de Kondor+, environ 150 personnes. En charge de la partie développement du plan de post acquisition, ma mission se déclinait en 3 axes : - intégrer 45 nouveaux collaborateurs - intégrer deux nouveaux produits DCM et DAM (Diagram Asset Management). - moderniser l offre DCM afin de fournir un module back office réellement intégré à Kondor+. Au cours d'une vingtaine de réunions et de visites j'ai identifié la dizaine de personnes clés et produit un organigramme qui intégrait les 45 nouveaux collaborateurs. Le déménagement physique qui a eu lieu 3 mois après l acquisition a permis d accélérer le processus de fusion. J ai rencontré les 45 nouveaux collaborateurs en entretien individuel, dégagé des schémas d évolution de carrières et un plan de formation. Un audit technique de DCM et DAM réalisé avec mes équipes a conclu à l impossibilité technique de faire évoluer DCM basé sur Power Builder. Six mois après l acquisition, j'ai présenté un scénario de création d un nouveau module back office avec les fonctionnalités de DCM et les librairies Kondor+, ce qui marqua le démarrage du projet K+TP (Kondor+ Trade Processing). J ai mis en place une équipe de 15 ingénieurs développement composée de 7 ingénieurs ex-diagram, 3 ingénieur Kondor+ et 5 nouvelles recrues. Le produit DAM, équivalent de DCM pour l Asset Management, a été considéré non stratégique par Reuters. J ai participé à la revente de cette activité à une société tierce en Août 2002 et à la séparation de 20 développeurs. 2
La première version de K+TP est sortie en avant-première en septembre 2004, pour être ensuite «bêta» en 2005. A ce jour, 2 clients sont en production et 5 autres sont en tests avancés pour l être. Reuters dispose aujourd hui d une vraie offre intégrée «front to back», ce qui a ouvert de nouveaux marchés dans le back office et en Asie et permis de réaliser de nouvelles ventes : a ce jour 12 clients ont opté pour cette offre augmentant du même coup les ventes du front office. Cette fusion fut réalisée sans pertes humaines : les 25 ingénieurs ex Diagram ont été efficacement intégrés dans mes équipes. 3
Les développements de Londres et New York rapatriés à Paris Économies de production et enrichissement de l'offre En 1999, 3 centres de développements issus du rachat de 3 sociétés différentes avec des cultures différentes et des méthodes de travails différents travaillaient pour la même famille de produits Trade & Risk Management au sein du groupe Reuters : - Puteaux, une soixantaine de personnes, le produit «front office» Kondor+, - New York, une trentaine de personnes, un produit middle office de calcul de «Value at Risk», KVaR. - Londres, une trentaine de personnes, un produit de gestion de limites, KreditNet. Les interfaces entre les produits Kondor+, KreditNet et KVaR+ nécessitaient beaucoup de travail de maintenance dans un contexte relationnel conflictuel. Reuters a d'abord décidé de susciter une collaboration entre les trois centres pour créer une offre intégrée avec ces 3 produits en deux étapes, KreditNet en 1999 et 2000 et KVaR+ en 2002 : - J'ai fait une évaluation technique de KreditNet et de l organisation (staff, méthodes et processus de développement) à Londres en 1999. - J'ai proposé deux options au business avec évaluation des avantages et des inconvénients de chacune d elles : changement d organisation tout en gardant 2 sites Londres et Paris ou fermeture d un seul site et rapatriement des développements sur le site restant. - J'ai mis en musique l option choisie : fermeture de Londres, rapatriement des sources à Paris, écriture d un livre blanc, création d une équipe de développement pilote pour réaliser un prototype du nouveau KreditNet, réalisation du prototype, agrandissement de l équipe de développement, lancement du projet et pilotage de la livraison. - Scénario reconduit en 2002 avec le centre de New York et le rapatriement de KVaR+ à Puteaux. Aujourd hui, les fonctionnalités de Kreditnet et de KVaR+ sont intégrées dans une offre Reuters KGR (Kondor Global 4
Risk) vendues dans la suite Kondor+. KGR avec 2600 utilisateurs dans le monde. Tous les développements «Trade & Risk Management» sont regroupés sur un seul site favorisant échange et partage (infrastructure, connaissance), et Reuters a réalisé des économies substantielles sur les voyages entre les 3 centres développement, plus une réduction de 50% des effectifs de production passant de 60 ingénieurs en 1999 à 30 aujourd hui.. 5
Pilotage des évolutions techniques de Kondor+ La compétitivité par les choix technologiques Ayant été un des pères fondateurs du logiciel Kondor+ en 1993, j'ai eu la responsabilité du produit en 1997 à la tête d un groupe de 45 personnes avec mission de le faire évoluer fonctionnellement et techniquement. En 1997, Kondor+ était entièrement basé sur une architecture client/serveur, et composé de 6 millions de lignes de code écrit en langage C, d une interface graphique sur station Unix (Sun Solaris / Xview) avec une émulation sur Microsoft Windows. On dénombrait 178 clients installés avec 3700 utilisateurs. Le cycle de développement d une nouvelle version était de 12 à 18 mois. Kondor+ devait évoluer pour suivre les évolutions technologiques et s agrandir fonctionnellement tout en préservant la base de clients installés en leur proposant un chemin de migration en douceur. Ces évolutions technologiques ont été réalisées en plusieurs phases par une approche incrémentale : - Adoption du langage objet C++ dès 1997 ; ceci a facilité le recrutement de nouveaux collaborateurs et amélioré le processus de conception des nouveaux développements grâce au paradigme objet. - En 1999, migration de la couche d accès à la base de donnée (Sybase/DBLib à Sybase CTLib) avec l ajout d une couche d abstraction ( «à la ODBC» ) pour permettre une évolution future vers Oracle. - Remplacement d un serveur de notification (Sybase/Open Server) par un middleware ouvert (Tibco/ Rendez-vous) en 2000. - Création en 2001 d une interface Web basée sur Java/J2EE pour Kondor+ avec un sous ensemble de fonctionnalités (saisie d opérations et rapport de P&L & risque). - En 2005/2006, Changement de l interface graphique de Sun/Xview vers TrollTech/Qt. La nouvelle interface graphique est disponible sur Sun/Solaris mais aussi Windows et Linux. 6
- En 2005/2006, migration de l architecture du mode client/serveur vers une architecture 3 tiers orientée service (SOA) par l adoption d un «Entreprise Service Bus». Ces évolutions ont permis au produit Kondor+ de rester très compétitif et en ont fait le logiciel le plus installé aujourd hui dans le monde sur ce type d activité. Tous les clients historiques présents en 1997 utilisent toujours Kondor+, et nous sommes passés de 3700 utilisateurs en 1997 à 13 000 utilisateurs aujourd hui et le CA est passé de 10 à 120 millions d euros. Processus d intégration de 80 nouveaux collaborateurs Une méthode rigoureuse et payante En 1996 nous souhaitions résoudre le problème suivant : comment professionnaliser l intégration de nouveaux collaborateurs dans le département de développement et accélérer leur prise de fonction sur un produit complexe avec 6 millions de lignes de codes? Mes actions pour les collaborateurs recrutés: - désignation d un parrain pendant toute la durée de la période d essai. - procédure d accueil à l arrivée avec planning détaillé du premier jour, de la première semaine et des 2 premiers mois. - élaboration d un programme de formations internes des 4 premières semaines : présentation des produits, de l environnement de développements, des librairies, etc. - création «de projets jouets» pour permettre de s entraîner dès la 5éme semaine à prendre son poste sans risque pour les développements en cours : familiarisation avec les librairies, l environnement de développement, les règles de programmation, etc. - mise en place d un entretien formel de milieu de période d essai. 7
Ce processus d intégration, fort apprécié de toutes les nouvelles recrues, a grandement contribué à la croissance des équipes de développements de 30 ingénieurs à 110 en 8 ans, tout en préservant les méthodes de travail et la culture. Ayant permis un taux de rétention supérieur à 95%, il a été appliqué à d autres services et repris dans le programme général d intégration de nouvelles embauches de la Direction des Ressources Humaines du centre de développements Reuters à Puteaux. 8
Outils et composants logiciels partagés par plusieurs applications Gouvernance technique, Cohérence d architecture et Économie de production A l automne 2002, Reuters se trouve dans la situation suivante pour son offre progiciel Trade & Risk Management : - une application principale Kondor+ avec deux interfaces graphiques, une interface lourde écrite en Xview pour des raisons historiques et une interface légère Web connue sous le nom de TradeAccess. - une application KreditNet pour la gestion de limite avec une interface lourde écrite en Java. - un projet naissant Kondor+ Trade Processing pour lequel une décision était à prendre : interface lourde et/ou légère, technologie Xview, Java ou autre. Reuters a par ailleurs l ambition de faire de son offre progiciel une ligne de produits cohérente et facile à utiliser, composée d'applications parfaitement intégrées, visuellement cohérentes, à l'ergonomie similaire. Mes actions et décisions : - Embauche d un ergonome à plein temps pour travailler sur la facilité d utilisation des interfaces graphiques et d un graphiste pour travailler sur le visuel des applications et leur mise en conformité avec les normes Reuters. - Décision d isoler le «squelette» de TradeAccess pour constituer la base d un «Framework» commun pour les interfaces graphiques légère Web. - Décision de privilégier les technologies Java/J2EE, Strust et XML en lieu et place du choix alternatif Microsoft ".net". - Décision de doter le nouveau produit Kondor+ Trade Processing d une interface unique légère basée sur ce Framework. - Imposer l adoption du même Framework pour la migration de KreditNet vers une interface unique légère (abandon de l interface lourde Java). - Création d une équipe de 5 ingénieurs dédiée au développement GUI (Graphical User Interface) et à la maintenance de ce Framework. Ce plan d action a porté ses fruits au bout de 2 ans : en fin 2004, les 3 principales applications Trade & Risk Management de Reuters avaient toutes la même philosophie d utilisation et le même visuel. Le choix des interfaces légères web s est avéré payant et en conformité avec les tendances technologiques actuelles. En 2006 un projet a été lancé pour migrer complètement les fonctionnalités de Kondor+ vers cette 9
technologie et abandonner à terme son interface lourde. L économie de production réalisée s élève à 50% (5 ingénieurs au lieu de 10) en plus des gains réalisés sur l effort de maintenance (un seul ensemble de composant partagés par 3 applications). L adoption des interfaces légères web a par ailleurs ouvert le marché de l hébergement des applications au business Trade & Risk Management de Reuters : ce type d utilisation génère 5 Millions sont par an. 10
Les prestataires de services dans la production Contrôle du savoir-faire Entre 2002 et 2005, Reuters applique son programme FAST FORWARD destiné à sortir la société du «rouge» par une gestion draconienne des coûts. Au niveau local, ce programme se traduit par une interdiction des embauches d ingénieurs sur des postes permanents de janvier 2003 à janvier 2005, l option préconisée étant les prestataires de services. Cela est un changement important de culture : nous privilégions jusque là l embauche de permanents du fait de la durée d apprentissage de nos produits et de nos environnements (3 mois) et de notre volonté de voir les ingénieurs rester le plus longtemps possible sur les applications qu ils développent (4 à 5 ans en moyenne). Pour des raisons légales, la durée maximale de la mission d un prestataire est fixée à 2 ans. Mes actions : - Sélection de 5 sociétés SSII fournisseurs de prestataires de services : basée sur les profils des ingénieurs, la culture de la société, etc. - Négociation des tarifs de prestations pour optimiser le budget alloué. - Sélection des projets et des tâches pouvant être confiés à des prestataires afin de limiter le risque opérationnel en cas de départ. - Mise en place d un plan accéléré d intégration de ces nouveaux collaborateurs : la prestation étant payée par jour, il n était pas question de passer 3 mois à leurs formation. - Mise en place d une politique de «Back up» systématique, le travail de chaque prestataire étant supervisé par un permanent. - Suivi du planning de prestation, anticipation et remplacement des départs, renouvellement en fonction de la performance, etc. Cette stratégie de gestion a permis d absorber des prestataires constituant jusqu à 25% des forces de développement en fin 2004 en gardant une bonne productivité et une bonne qualité dans les livraisons. Au total plus de 50 prestataires sont passés dans les équipes de développement sans perte de connaissance ni de contrôle sur aucune partie de nos applications. À partir de janvier 2005 nous avons pu renverser la tendance pour se stabiliser aujourd hui à 10% de prestataires dans les effectifs de développement. Cette expérience s est avérée très bénéfique : nous avons appris à monter en charge ponctuellement en faisant appel à de la prestation pour faire face à des pics de production. 11