Off-shore et méthodes agiles

On rencontre régulièrement deux types de motivation pour utiliser des ressources off shore : la recherche du moindre coût ou la dimension du bassin d'emploi quand le marché de l'emploi on-shore est saturé. Même si la première motivation est de loin la plus répandue, surtout dans la période de crise actuelle, la seconde existe aussi dans des périodes où l'emploi on-shore est très tendu du fait d'une très forte activité. Dans ces deux approches, on recherche l'acquisition d'une force de développement soit parce que l'on pense qu'elle sera moins chère, soit parce que l'on peine à la constituer on-shore.

Ce qui est frappant, c'est le décalage fort entre le message dispensé on-shore et off-shore. Les entreprises se plaisent à dire que les hommes constituent leur principal capital alors qu'elles vont chercher off-shore des ressources sur lesquelles elles n'ont que peu de maîtrise en privilégiant les coûts. Dans certaines entreprises, on constitue des équipes on-shore avec des profils de haut niveau et on improvise complètement le recrutement off-shore, laissant le soin à des prestataires ou à des intermédiaires de monter ces équipes off-shore.

Tel que présenté ici, le constat pourrait paraître caricatural, pourtant, on peut mesurer la réalité de ceci à travers le nombre de d'entretiens réalisés par les responsables d'équipes on-shore pour sélectionner les membres des équipes off-shore : combien prennent la peine d'aller régulièrement sur les sites off-shore entretenir le contact avec les équipes et recruter les nouveaux embauchés ? Autre élément de mesure, on peut avec quasi certitude, affirmer que tous les responsables d'équipe connaissent la valeur relative des formations dispensées on-shore. Cet élément est indispensable pour aider à créer des équipes équilibrées. Combien de ces mêmes responsables connaissent les filières des pays off-shore dont ils utilisent les ressources ?

Se pose également, pour les grandes entreprises, la question de la structuration du pôle off-shore. Faut-il acheter du service à des sociétés locales, disposer de sa propre structure ou tenter une solution mixte ? Il n'y a certainement pas de réponse unique à cette question : tout dépend de la stratégie et de la notoriété de l'entreprise. Des sociétés peu connues mondialement et peu connues dans les pays off-shore auront du mal à attirer les meilleurs profils qui se dirigeront le plus souvent vers des entreprises connues ou leur offrant des possibilités de travail en occident. Pour ces sociétés dont la notoriété est moins grande, le recours à la sous-traitance à travers les sociétés de service locales est sans doute la bonne solution. Pour les autres, une installation locale peut être à considérer.

Quelque soit la solution retenue, soit parce qu'une solution de sous-traitance a été mise en place, soit du fait de la création d'une « Business Unit » distincte, une relation de type client-fournisseur s'installe entre l'équipe on-shore et l'équipe off-shore.

De ce fait et également du fait de l'éloignement culturel et géographique, les méthodologies de développement en cycle en « V » ont la préférence des managers qui pensent pouvoir ainsi mieux maîtriser les développements réalisés off-shore. Ces méthodes introduisent, dans les différentes phases du cycle en « V », des ruptures entre les équipes. L'articulation entre spécifications et développements n'est pas facile à réaliser sans perte d'informations et les exemples de dysfonctionnement à ce niveau sont très nombreux. L'adoption de telles méthodes dans un contexte on-shore/off-shore rend encore plus problématique l'articulation entre Maîtrise d'œuvre et d'ouvrage. La distance culturelle et géographique joue à plein pour gêner la compréhension entre les équipes, par ailleurs, peu favorisée par les méthodes en cycle en « V ».

Pour éviter ces écueils, on essaye de fluidifier la relation entre les équipes on-shore et off-shore en mixant par exemple, quelques personnes des différentes équipes. Même si ces dispositions améliorent le fonctionnement, elles n'éliminent pas les frottements et introduisent des coûts supplémentaires.

Globalement, du côté des coûts, les économies sont moins substantielles que la différence de taux horaire ne le laisserait supposer. Si l'on regarde uniquement l'aspect coût sans prendre en compte ni la qualité ni les fonctionnalités fines, l'économie communément admise par la profession est d'environ 20%. Même si cela n'est pas négligeable, il n'est pas évident que l'off-shore soit aussi attractif lorsque l'on prend en compte tous les aspects mesurables ou non mesurables.

Tout ceci montre que la façon traditionnelle d'envisager le développement off-shore n'est pas optimale car elle introduit beaucoup d'inefficacités. Pour améliorer cette situation on peut avoir l'idée d'introduire les méthodes agiles dans le développement off-shore. Ces méthodes proposent de simplifier et d'accélérer le cycle de développement en évitant les « effets tunnel » et en essayant de limiter l'incompréhension entre les équipes, notamment avec les utilisateurs. Sans chercher à décrire ici ces méthodes, elles apportent généralement des cycles ou itérations de quelques semaines au bout des quelles un livrable doit être produit et le possesseur de l'application doit mesurer la valeur ajoutée et définir le contenu de l'itération suivante.

Étant donné le format très réduit de chaque itération, la communication au sein de l'équipe et avec les autres équipes est primordiale et souvent organisée à travers des réunions quotidiennes. Lors de ces réunions, l'équipe retrace les travaux et difficultés de la veille et établit le plan de la journée. Ce mode de fonctionnement paraît assez peu compatible avec un mode off-shore. Cependant, les capacités de communication actuelles permettent la tenue de réunions quotidiennes en visio conférence qui rassemblent les équipes même localisées en différents endroits. L'adoption d'une méthode agile va réunir les équipes on-shore et off-shore sur un même projet en structurant et en organisant une forte communication dans l'équipe, en mettant en place une méthodologie de travail commune et fédérant l'ensemble des acteurs sur des objectifs communs régulièrement revus. Les décalages et incompréhensions inhérentes à la distance sont ainsi détectées plus facilement et surtout plus rapidement. Les conséquences de ces problèmes sont donc mieux maîtrisées ce qui en limite les coûts.

Mais la mise en place de telles méthodes ne peut s'envisager sans une révision drastique du recrutement : il n'y a plus d'équipe off-shore et on-shore mais une équipe unique travaillant en plusieurs endroits sur le même projet. Le recrutement de tous les membres de l'équipe doit s'effectuer d'une façon homogène quelque soit le site. C'est d'ailleurs une condition nécessaire au respect indispensable au fonctionnement interne de l'équipe. Cela a également un impact sur la structure organisationnelle du site off-shore : il est plus facile d'organiser ce type fonctionnement avec des filiales off-shore qu'avec des prestataires sur lesquels le contrôle du recrutement sera moins aisé.

Pour finir sur une note légèrement provocatrice qui résume le raisonnement sous-tendant cette proposition, on pourrait dire : étant donné les formations de qualité existantes dans les pays off-shore, pourquoi les ingénieurs de ces pays seraient-ils moins compétents que les nôtres et pourquoi ne pourraient-ils pas travailler dans les mêmes équipes ?

Génération de code et off shore

La délocalisation touche maintenant depuis quelques années les métiers de l’informatique et plus spécifiquement les métiers du développement. Il n’est donc peut-être pas inutile de regarder des expériences plus anciennes, notamment dans l’industrie, pour tenter de trouver des enseignements.

Avant de se lancer dans cette démarche, il faut cependant bien garder en tête la nature des activités de développement. Ces dernières, même si l’on parle communément de production de code, restent des activités d’ingénierie et non des activités de production. La transposition des expériences de délocalisation qui concernent essentiellement des activités de production est donc à mener avec circonspection.

D’une façon un peu caricaturale, on peut dire que dans l’industrie le niveau d’investissement est inversement proportionnel au coût de la main d’œuvre. La délocalisation permet donc de bénéficier de main d’œuvre moins chère et donc de mobiliser moins de capitaux pour produire au même coût que dans d’autres pays où la main d’œuvre est plus coûteuse. D’ailleurs, le niveau d’automatisation est calibré sur des hypothèses de coûts de main d’œuvre : si le succès d’un pays provoque un renchérissement de la main d’œuvre, les hypothèses de départ peuvent ne plus être vérifiées entraînant une nouvelle délocalisation vers des pays moins chers. Les pays de l’Europe de l’est ont été victimes de ce syndrome dans les années 90.

Pour revenir maintenant au monde du développement, la même analyse peut être menée : à productivité égale, même en tenant compte des coûts de frottements liés aux distances et aux différences de culture, la délocalisation est plus économique. Cependant, en regardant bien cette proposition, on peut travailler sur son hypothèse fondatrice qui tend à considérer la productivité comme égale entre des développements « on shore » et des développements « off shore ».

On retrouve ici la notion, abordée plus haut, de niveau d’investissement ou niveau d’outillage : comme pour une usine on peut plus ou moins industrialiser la production de code et améliorer la compétitivité des pôles de développement « on shore » par des outils de génération de code.
Le parallèle avec l’industrie n’est cependant pas possible complètement : la lourdeur des investissements nécessaires à l’automatisation d’une partie du développement d’une application n’a rien de commun avec les coûts des robots d’une chaîne de montage ! En revanche, comme dans l’industrie, cette apparition de l’automatisation a un impact sur les ressources. Moins de ressources plus qualifiées seront nécessaires pour mener à bien un projet.

L’utilisation des techniques de génération de code est donc une réponse à la menace que fait peser « l’off-shoring » sur les développeurs occidentaux. Ces techniques ne doivent pas être considérées comme des menaces sur le rôle du développeur mais comme une opportunité à la fois pour s’abstraire des tâches les plus rébarbatives du développement et également pour améliorer sa compétitivité face à des solutions off-shore. Libérée d’une partie des développements, l’équipe projet peut alors se concentrer sur la définition des fonctionnalités, la proximité avec les utilisateurs, bref sur tout ce qu’il est difficile de faire « off shore » !

Créativité et Génération de code

Certains pourraient penser que la génération de code et la modélisation en général vont brider la créativité de leurs développements en leur imposant un carcan dont ils ne pourraient s’échapper !

Cette vision de la modélisation est très restrictive : elle laisse à penser que l’approche modélisation s’utilise comme une boîte noire dans laquelle on rentre un modèle et dont il ressort une application prête à l’emploi.

Si certaines approches MDA tentent de simplifier à l’extrême la génération d’applications (approche Crud par exemple), il est largement entendu que ces approches ne permettent que la générations d’applications très simples voire simplistes. Le MDA ne se résume pas à ces approches : dans nombre de cas d’utilisation, ces techniques sont utilisées sur des parties du projet laissant au concepteur la possibilité d’exprimer sa créativité dans les autres parties et dans la pertinence de la solution.

Pour rester sur ce sujet de créativité, on peut décomposer l’apport de la créativité aux activités de programmation sur deux axes : la créativité fonctionnelle et la créativité technique. Pour la première, l’approche modélisation/génération est extrêmement bénéfique : moins on passe de temps à coder plus on est disponible pour travailler sur les aspects fonctionnels, plus la solution apportée par l’application est innovante ou en adéquation avec les besoins de l’entreprise.
Pour la créativité technique, en première approche, il pourrait en être différemment : où trouver de la créativité dans des tâches largement automatisées ? En fait, la créativité se situe alors à un autre niveau : dans la conception du template de génération. C’est dans cet élément essentiel à la génération automatique que l’on retrouve les capacités créatives et d’innovation des développeurs. C’est dans la qualité du template que l’on retrouvera les performances de l’application, la qualité du code qui, soit dit en passant, ne doit pas être de qualité inférieure à celle d’un code écrit manuellement. La créativité technique reste absolument nécessaire pour imaginer ces solutions innovantes porteuses de gain de productivité.

Pour finir, et pour replacer dans le contexte réel les défenseurs de la créativité, quel est le réel pourcentage de code « créatif » dans les applications ? Peut-on vraiment parler de créativité quand on passe une bonne partie de son énergie dans l’écriture de code transformant des données d’une représentation dans une autre ? N’est-il pas préférable d’utiliser une machine pour ces tâches pénibles et répétitives ?

Outils de Workflow

Pour les outils de workflow, comme pour beaucoup d'autres technologies, les concepts ne datent pas d’hier. Ces outils tentent de donner un support informatique à la mise en place de procédures opérationnelles. Les directions de l’Organisation de nombreuses sociétés ont utilisé des outils de cette nature d’abord pour modéliser les processus, puis pour les mettre en œuvre. Des consortiums ont travaillé depuis des années sur la normalisation des outils qui sont restés très souvent confinés au monde du traitement documentaire.


L’objectif de ces outils est de décrire, souvent à travers une interface graphique, les différentes étapes d’une procédure mettant en relation différents intervenants et une demandant le respect d’une séquence. Après avoir été descriptifs, ces outils ont proposé des moteurs permettant alors de mettre en œuvre opérationnellement les procédures décrites. Ces outils ont ainsi permis la collaboration des différents intervenants en orchestrant les échanges et les validations. Le passage du descriptif à l’interactif a d’ailleurs alimenté bien des querelles entre Directions Informatiques et Directions de l’Organisation !


Comme mentionné plus haut, ces outils ont été utilisés pour des procédures documentaires. N’ayant aucun lien profond avec le reste du système d’information, ils ne pouvaient pas orchestrer les échanges inter applicatifs même si, technologiquement, ils en avaient depuis longtemps la capacité.
Si on imagine facilement l’importance de la formalisation des procédures, l’émergence des processus de normalisation Iso ayant matérialisé cette nécessité, on sait moins que la plupart des systèmes d’information des entreprises cachent dans leurs applicatifs des procédures implicites dont la connaissance disparaît au fil des années.


Pour illustrer ceci on peut prendre le cas de ces entreprises qui disposent de filiales en différents points du globe, chacune opérant sur des systèmes différents. Le groupe cherchant néanmoins à mettre en place des traitements consolidés pour dégager des économies d’échelle, la mise en place d’échanges inter applicatifs devient alors essentielle. Inévitablement, au gré des restructurations, ces règles d’échanges évoluent impliquant une reconfiguration du système d’information.
On parle alors de rigidité du système d’information car, l’adaptation du système aux nouvelles règles métier est longue voire pénible. Pour réaliser ces adaptations, on est souvent obligé de se réapproprier les règles d’origine dont la connaissance a été perdue, puis on tente d’implémenter les nouvelles règles dans tous les applicatifs concernés.
Le monde du Workflow, jusqu’à la naissance de la SOA, restait étranger à ces problèmes d’intégration et d’échanges inter applicatifs

Intégration de Services et Urbanisme

Sans remonter aux origines de l’informatique, l’intégration de service existe depuis longtemps. On trouve dans les Remote Procedure Call (RPC) des tentatives d’intégration de systèmes ; ceci a trouvé un prolongement dans DCE , Corba, J2EE et finalement dans les fameux WebServices.
L’intégration de service par opposition à l’intégration de données consiste à rendre accessible des traitements à une application cliente. Il ne s’agit pas de fournir à cette application cliente des données extraites d’une base mais bien de fournir à la demande des traitements utilisant les données fournies par l’utilisateur.

Les raisons qui poussent à la mise en œuvre de ce type d’intégration sont nombreuses mais la principale, Graal de l’informatique depuis des années, est la réutilisation. En effet, ces technologies d’intégration rendent possible la réutilisation d’une partie d’un système exposé sous la forme d’un service.
Pour illustrer ceci, on peut prendre l’exemple souvent observé du système legacy fournissant des fonctionnalités indispensables au bon fonctionnement de l’entreprise. Malheureusement, ces ressources sont plus ou moins verrouillées dans une architecture fermée ou dans une technologie ancienne et par ailleurs, le coût de portage de l’ancienne application dans une architecture plus ouverte s’avère plus que prohibitif voire impossible. Les technologies telles que celles mentionnées précédemment ont alors été utilisées pour fournir des services de base à de nouvelles applications apportant de nouvelles fonctionnalités.

Un exemple concret vécu au début des années 90 : une entreprise disposait d’un moteur de calcul financier de plus d’un million de lignes de Fortan 66 associé à une base de données propriétaire elle aussi assez vaste. Arrivent à cette époque les stations de travail sous Unix, qui donnent aux utilisateurs des possibilités ergonomiques et graphiques sans précédent. Mais comment bénéficier des ressources du « legacy » sur les stations de travail sans porter dans le nouvel environnement le moteur de calcul et ses données ? La définition d’une abstraction de ce moteur de calcul a permis l'implémentation sur le système legacy d’un service utilisable par les nouvelles applications développées sur les stations de travail

Cet exemple qui présente une réutilisation pragmatique et plutôt technique montre cependant la composante fonctionnelle inhérente à l’intégration de service. Le sujet n’est pas que technique : qui dit intégration de service dit définition des fonctionnalités de ce service.
Dans certaines entreprises, une analyse plus en amont et plus fonctionnelle de la réutilisation a été menée à travers les travaux d’urbanisation du système d’information. L’intégration de service peut être le support de ces réflexions sur la réutilisation permettant de donner une réalité aux concepts manipulés par les urbanistes.