Le Blog Faciliware

Continuité du Service et Plan de Reprise des Activités - Retour d'expérience

Arnaud Pain, nous vous remercions pour votre présence sur notre Blog avec cette intervention concernant la mise en place des solutions de PRA (ou Disaster Recovery Plan, DRP).

Avant de commencer, pourriez-vous nous dire quelques mots sur vous, sur votre société / ses activité?
MTRC-Consulting est une SSII du Nord de la France créée en mai 2005. Nous intervenons principalement sur les technologies Microsoft, Citrix, le Stockage et la Virtualisation ; tant en France qu’à l’étranger. Nos références clients sont diverses et variés (Finance, Santé, Collectivité territoriale, …).

Comment vous vous êtes orienté vers le PRA?
Avec l’un de nos clients parisien qui travaille dans la finance, nous avons été confrontés à la problématique de mise en place d’un PRA. Nous avons donc conseillé notre client sur les solutions possibles et nous avons retenu le choix qui nous semblait le plus judicieux et le moins onéreux, à savoir la mise en place d’une copie de ses serveurs en environnement virtuel.
Nous avons ensuite travaillé sur une offre globale incluant l’hébergement du PRA (serveurs virtuels, …) dans nos locaux.

Selon vous, y-a-t-il des spécificités pour les PME/PMI, dans ce domaine?
Nous ne pensons pas qu’il faille faire 2 poids 2 mesures en ce qui concerne le DRP, les petites structures ont tout autant besoin de DRP que les grands groupes.
La principale différence réside dans les moyens financiers qu’ont les uns et les autres, c’est pourquoi nous avons voulu proposé à nos clients et prospects une offre adaptée à leurs besoins et surtout à leurs budgets.

Pour ce faire, nous proposons 2 types de solutions de Virtualisation, l’une basée sur le leader du marché à savoir VMware, l’autre sur un acteur en devenir XenSource.

Toutefois, certaines entreprises sont dans l’obligation de mettre en place un PRA ou un PCA:
a) Société cotée sur les marchés Américain
Loi : Sarbanes-Oxley Act de 2002 / NYSE Rule 446 / NASD Rule 3510 & 352;
Obligations en matière de PCA : Assurer la mise en place et le maintien en condition opérationnelle d'un PCA (NYSE Rule 446 / NASD Rule 3510 & 3520). D'une façon générale mettre en oeuvre les solutions et processus permettant d'éviter une situation de faillite financière ( Sarbanes-Oxley Act )
b) Une banque, un établissement de crédit ou d'investissement
Loi : Règlement CRBF 97-02 et 2004-02 (retranscription française de l'accord Bâle II)
Obligations en matière de PCA : Vous devez assurer la continuité de l'exploitation informatique en cas de difficulté grave dans le fonctionnement des systèmes. Vous devez assurer la continuité de l'activité des établissements financiers en élaborant et décrivant de façon détaillée un PCA documenté, cohérent et testé. Etre en mesure d'apporter la preuve des éléments indiqués ci-dessus en cas d'audit par la Commission Bancaire.
c) Une société d'assurance ou mutuelle d'assurance
Loi : Accord de Solvency II en préparation, sur le modèle des accords de Bâle II

Comment est-ce que vos clients vous approchent? Décrivez-nous, le cas échéant, leur profil-type.
Le besoin d’un DRP n’était pas jusqu’ici un des principaux objectifs des DSI mais, il commence à le devenir. En général le facteur critique n'est pas le coût de mise en œuvre d’un tel projet mais les coûts d'un éventuel « crash » du système.
Après, dans notre approche, nous mettons en avant les outils que nous utilisons, notamment des outils de calcul de charges des serveurs (sans installation d’agents), qui vont nous permettre de dimensionner au plus juste l’infrastructure nécessaire à la mise en place du DRP.

Avec votre retour d'expérience, quelles seraient les« meilleures pratiques » pour une telle démarche?
Il est évident que dans ce genre de projet, l’équipe du client doit être impliqué dès le départ, il est intéressant, lors d’un rendez-vous de pouvoir discuter avec le DSI et tout ou partie de son équipe pour leur expliquer les tenants et les aboutissants ainsi que la maîtrise technique que nous avons des produits que nous proposons.

Quels sont les solutions du marché, dans ce domaine?
Il est existe plusieurs logiciels permettant de gérer un DRP, nous avons fait le choix de ne retenir qu’un petit nombre d’entre eux, ce qui nous permet de mieux maîtriser l’ensemble des éléments à mettre en œuvre, puisque nos ingénieurs sont certifiés par les éditeurs de ces logiciels.

Est-ce que des gains qualitatifs et/ou quantitatifs peuvent être identifiés?
Il est difficile de quantifier les gains pour les clients, d’une part parce que chaque client à des problématiques différentes (notamment par rapport au temps d’indisponibilités de son IT qu’il peut « supporter ») mais aussi parce que cela dépendra des solutions retenues. Toutefois, on peut avancer quelques chiffres issus d’études réalisées par Gartner Group, à savoir 70% des entreprises ayant vécu un sinistre sans avoir mis en place auparavant un plan de secours, déposent le bilan dans les 2 ans.

Pouvez-vous identifier des points particulièrement significatifs pour ce type de projet?
Les points importants sont les délais nécessaires pour remettre en route tout ou partie d’un système d’information, sachant qu’il est possible soit d’avoir un site distant soit une salle machine distante (mais sur le même site).

L'informatique à valeur ajoutée: analyse

Depuis les 5 dernières années, les études sur les dépenses informatiques montrent que "mieux dépenser" passe par les investissements à valeur ajouté. Ce faisant, l'apport métier de l'informatique est devenu un critère d'hiérarchisation des projets bien plus important que leur coût et les Directions générales sont désormais les premières à demander aux DSI de l'innovation et réactivité. Quelles pistes pour  répondre aux attentes de chaque segment de clientèle (externe ou interne)?

L'hypothèse de départ: un constat
A la fin de l'année 2003, Accenture publiait un whitepaper sur "La recherche de la valeur, ou comment hiérarchiser les investissements informatiques", basé à la fois sur l'étude des dépenses informatiques et de personnel de Gartner Group (2001) et sur sa propre enquête  "Business value creation through IT" (2003).
Le constat principal portait sur le fait que les entreprises à la traine et les entreprises leader de leurs secteurs respectif dépensent moins que la moyenne! cependant, le premier cas reflète une réduction des investissements, alors que les entreprises leader dépensent moins car mieux: c'est à dire dans des investissements à valeur ajoutée. Les quelques exemples illustrées démontraient une anticipation stratégique de la part des entreprises ayant mis en place de tels investissements - l'affaire était à suivre.

Les attentes des Directions Générales
Nous suivons donc l'affaire, avec, à la fin de l'année 2006, un évènement organisé à Paris par IDC - le "European IT Forum 2006" - sur le thème "Innovation et globalisation : quelles conséquences sur les DSI ?". Parmi les communiqués, les résultats d’une enquête auprès des Directions Générales et des DSI concernant le rôle de la DSI en matière d’innovation.
Cette fois, il semble bien que les Directions Générales sont décidées à demander "mieux", non pas "moins" aux DSI: questionnées sur le message à faire passer aux DSI, la diminution des coûts informatiques passe en dernier, la demande d'apporter davantage de services à valeur ajoutée pour le métier la surpasse (voir, devient la plus importante pour les entreprises à plus de 1000 salariés).

De plus, en 2006, 1 dirigeant sur 3 (contre 1 sur 6 en 2005) affirme que la réactivité de l'informatique est un des axes majeurs sur l'agenda de l'année à venir.

Et une démarche pour y arriver
En début 2007, IBM publiait une étude ayant pour titre "La simplification de l’IT pour répondre aux objectifs de l’entreprise" ( © Copyright IBM Corporation 2007). L'étude montre que l’informatique doit mettre en oeuvre ses ressources de manière à déployer ou à maintenir les technologies nécessaires pour répondre aux attentes de chaque segment de clientèle (externe ou interne).
La fonction informatique est analysée selon les services proposées à l'ensemble de l'entreprise, avec des pistes d'évolution pour chacune des catégories. Ainsi, on parle de
- “services de base” : permettant d’automatiser des fonctions administratives essentielles au meilleur coût possible. Dans la simplification d’un département informatique axé sur ce profil, la priorité est généralement d'identifier un portefeuille de services standard et d'en réduire le coût.
- “services à la demande”: qui s’attachent principalement aux coûts tout en reconnaissant l’importance de la satisfaction client. Dans ce cas, les entreprises peuvent tabler sur la simplification de l’IT pour améliorer la qualité du service, et notamment les temps de réponse, la disponibilité et d’autres aspects du service client.
- l'informatique comme “activité partenaire” : les services informatiques sont évalués au niveau opérationnel. Les coûts restent importants, mais les efforts de simplification visent des gains opérationnels dérivant d’un investissement dans les technologies de l’information. Dans ce contexte, les unités opérationnelles établissent des relations de partenariat avec les départements informatiques pour atteindre des objectifs de qualité de service, de rentabilité et de capacité de mise en oeuvre de nouveaux services opérationnels innovants.
- La “ressource stratégique” : l’informatique est un élément important – voire même indispensable – pour la mise en oeuvre de la stratégie
commerciale ; par exemple, le commerce en ligne. Partie intégrante de la stratégie de l’entreprise, les projets informatiques sont considérés comme
essentiels à la compétitivité. Il est vital pour ces entreprises de pouvoir toujours retirer le maximum d’avantages de la technologie. L’informatique les aide à atteindre leurs objectifs d’innovation en matière de modèle économique en leur fournissant une infrastructure informatique extrêmement fl exible, adaptable et ouverte, capable de connecter rapidement de nouveaux partenaires commerciaux.

Il est fortement probable que les 4 profils de services coexistent au sein d'une même entreprise. C'est pour cela que META Group recommande une catégorisation des portefeuilles projet selon 3 types de base:
a) les portefeuilles des projets opérationnels (de l'ordre des services de base), comptant pour l'infrastructure applicative et technique,
b) les portefeuilles des projets commerciaux, visant à augmenter les ventes ("à la demande" ou "partenaire"),
c) les portefeuilles des projets transformant le business model ou visant des nouveaux marché  ("partenaire" ou "stratégique").
Ce faisant, dans l'arbitrage de la planification stratégique, la prioritisation peut passer par des critères de sélection croisés (importance stratégique et cible, valeur ajoutée et niveau de risque... ) auxquels s'ajoutent les aspects concernant les ressources humaines et budgétaires, afin de s'assurer que l'entreprise dispose des moyens nécessaires à la réalisation des projets.

Laboratoires Bouchara-Recordati: un retour sur la première implémentation SAP/AS400 en France

Bonjour, monsieur Vinceneux, vous êtes le Directeur Informatique des Laboratoires Bouchara-Recordati. Pourriez-vous nous présenter, en quelques mots, les activités de Bouchara ainsi que votre service?

Les laboratoires Bouchara-Recordati, filiale française du groupe pharmaceutique Recordati (basé en Italie à Milan), a réalisé en 2005 un chiffre d’affaire de 156 millions d’euros. Plus de 400 personnes y travaillent dont 250 sont itinérants (principalement des visiteurs médicaux), et 80 personnes sont rattachées à l’usine de fabrication situé à St-Victor dans l’Allier. Le laboratoire commercialise des spécialités dans les domaines du cardio-vasculaire, de l’ORL avec une large gamme de médicaments génériques

La direction informatique est constitué d’une équipe très réduite de 3 personnes, avec une partie info-gérée pour l’administration des réseaux et serveurs windows, et le HelpDesk utilisateurs. Nous avons dans l’équipe interne un développeur ABAP (langage de développement SAP).

Pourriez-vous nous décrire votre Système d'Informations?

Le système d’information est principalement basé sur l’ERP SAP. Nous utilisons Lotus Notes comme système de messagerie et un progiciel dédié pour la partie RH/paie. Toutes ces applications fonctionnent sur 2 serveurs iSeries dont un est réservé à SAP.

Nous avons aussi d’autres applications métiers (gestion de la trésorerie, notes de frais…) qui sont hébergées sur des serveurs Windows.

Vous avez implémenté SAP il y a 10 et dans un environnement comme le votre, c'était un projet unique. Comment cela s'est passé?

Le choix de SAP a été fait par les laboratoires Bouchara en 1996, dans le but de remplacer le logiciel comptable ne répondant plus aux besoins, notamment en terme d’analyses. Le périmètre de l’implémentation de SAP concernait donc les modules FI/CO (comptabilité, contrôle de gestion) ainsi que MM pour la gestion des achats. En 2002, puis 2006 les fonctions de SAP ont été élargies pour la gestion de toutes les activités de l’entreprise (achats, gestion des stocks, production, ventes, comptabilité, contrôle de gestion…). Nous profitons ainsi de toute la puissance de R3 en terme de système intégré.

Dés le début, le choix de Bruno Delcour, à l'époque DSI des Laboratoires Bouchara, c’est porté sur une architecture basée sur des AS400, correspondant à la culture et aux compétences du service informatique. Ce choix a été confirmé lors des évolutions de version SAP et de serveur.

Quel est le point fort de votre projet?

L’AS400 est devenu un serveur de plus en plus ouvert et compatible avec les protocoles et langages standard (sql, ip, java…), ce qui à permis à SAP de proposer son ERP sur cette plate-forme. Les Laboratoires Bouchara ont été les premiers en France à implanter R/3 sur AS400 en 1996, bénéficiant ainsi d’un suivi particulier de la part d’IBM et SAP durant le projet.

Aujourd’hui encore nous tirons les bénéfices de ce choix. Par exemple, de nombreuses interfaces EDI avec SAP ont pu être développées en interne en s’aidant des langages propres aux serveurs iSeries, tel que CL ou RPG, que nous maîtrisons parfaitement.

Qu'est-ce que cela a changé pour vous?

Les Laboratoires Bouchara avaient déjà des serveurs AS400 pour l’hébergement de leurs logiciels de gestion, tel que COMPTOS pour la partie comptable. La gestion commerciale était un développement interne développé sous ADELIA.

A l’origine nous avions 2 serveurs AS400 pour SAP, un pour le système de production, et un autre hébergeant les systèmes de test et de qualification. Aujourd’hui, nous avons consolidé tous les environnements SAP un iSeries 810 et nous utilisons (plus ou moins partiellement) les modules SAP R/3 suivants  : FI/CO, CO/PA, MM, PP, QM, SD.

Comment le projet est apprécié aujourd'hui par les utilisateurs?

Du point de vue des utilisateurs SAP, le choix technologique du serveur est totalement transparent. Nous utilisons le client SAP-GUI standard pour accéder à SAP au niveau des postes de travail. Les utilisateurs ont donc pu bénéficier de toute la puissance et de l’interface graphique de SAP sans restriction.

Quels sont les effets pour l'équipe informatique?

Pour l’équipe informatique, qui utilisait déjà des serveurs AS400, le premier avantage était de rester sur des technologies maîtrisées en interne et reconnues comme étant très fiable. SAP fonctionne sur iSeries avec les dispositifs standards de l’OS400 ainsi que DB2/400. Pas besoin donc d’acquérir de logiciel complémentaire, ni d’une base de données type Oracle, qui sont nécessaire pour les autres plate-formes. Pour les travaux d’exploitation, nous utilisons les outils inclus dans l’OS comme le planificateur de travaux. De ce fait, l’administration du serveur SAP ne nécessite que peu de ressources.

L’autre avantage est aussi de pouvoir utiliser les outils de développement de l’OS400 (CL, RPG, Query…) pour certains besoins, comme les interfaces. Ou encore certaines statistiques commerciales, que nous n’avons pas encore migrées, et qui sont toujours générées aujourd’hui sous RPG/ADELIA avec des données en provenance de SAP.

Quels ont été les facteurs de succès de votre projet?

La maîtrise de l’environnement technique nous a permis de nous concentrer sur la partie fonctionnelle du projet.

Lors de l’implantation du module SD (gestion commerciale), en 2006, de nombreuses interfaces étaient à développer avec nos partenaires externes (clients, distributeurs). Pour leur réalisation nous avons pu utiliser les langages natifs de l’iSeries (CL, RPG) jumelés avec les outils d’interfaçages standard SAP (IDOC). Les programmes RPG génèrent ou traduisent les fichiers IDOC SAP pour les interfaces entrantes ou sortantes. Cela permet de rester complètement dans le standard SAP pour les interfaces, tout en maîtrisant en interne les futures évolutions.

Quels sont les écueils à éviter?

Les bénéfices sont effectivement encore plus évident dans une structure maîtrisant les technologies iSeries. Pour une équipe ne connaissant pas ces serveurs il faut prévoir les formations suffisantes, qui s’ajoutent aux formations SAP dans le cadre d’un déploiement total.

Concernant les coûts de déploiement, une étude doit être effectué en prenant compte tous les éléments. Certes les machines iSeries coûtent plus cher à l’achat que les serveurs sous Windows ou Unix. Cependant les environnements SAP pourront être consolidés sur un même serveur iSeries, là ou il faudrait démultiplier les systèmes sur les autres plates-formes. Des économies sont donc réalisées sur les OS, les bases de données (DB2 est intégré à l’iSeries) et sur le temps-homme pour l’administration et l’exploitation des systèmes.

Le seul problème de cette solution est qu’elle n’est pas encore assez répandu dans la communauté SAP, du moins en France.

SOA pour l'urbanisation du SI

Philippe Noël est consultant spécialisé dans les architectures distribuées (J2EE et .NET), SOA et urbanisation. Il intervient depuis plusieurs années, en tant que architecte,  au sein de projets ou de structures pour proposer et mettre en place une démarche SOA ou d’urbanisation quand une entreprise est convaincue de l’intérêt de cette démarche. De façon plus pragmatique, il présente une approche concrète qui porte sur la mise en place d’une SOA au sein de projets sur mesure développés en régie.

Comment pouvez-vous nous décrire l'approche SOA?

La SOA propose une organisation et le développement de projets recentrés sur le fonctionnel à travers l’offre et la définition de services. Le SOA n’est pas une approche technique, même si on relie souvent le SOA aux services Web. Le SOA est donc une approche d’abord et avant tout organisationnelle de type urbanisation.

Peut-on faire une parallèle avec les approches précédentes?

Les dernières évolutions ont été essentiellement techniques (J2EE, .NET, Web Services, frameworks…). S’il y a eu un gain incontestable en terme de productivité, il y a bien des points qui n’ont pas été réglés : la réutilisabilité de composants, promise par l’objet, est souvent un vœu pieux. C’est vrai au sein d’un même projet, c’est encore plus vrai pour la communication entre projets qui est souvent inexistante et irréalisable pour des raisons autant organisationnelles que techniques. La communication entre le business et les équipes techniques est souvent un point faible qui peut entraîner des inadéquations entre les spécifications et le résultat, ou encore un time-to-market qui peut être amélioré. La complexité croissante des projets rend difficile leur maintenance, leur évolutivité et la rationalisation des outils. L’application des concepts portés par le SOA (couplage faible, définition de services et approche top-down, services sans états…) à différents niveaux (entre projets ou au sein des projets eux-mêmes) permet d’améliorer très fortement ces problématiques. La différence avec les approches précédentes est qu’il ne s’agit pas de l’émergence d’une nouvelle technologie, d’un nouveau protocole ou d’un nouveau standard, mais d’une approche organisationnelle.

Comment réussir à structurer une approche SOA ?

Tout d’abord, il n’est pas nécessaire de faire partie du top 10 du CAC 40 pour mettre en place une architecture orientée services, même si la SOA aujourd’hui s’applique d’abord à des entités qui font du développement sur mesure (les progiciels n’intègrent pas encore vraiment ces concepts, ou de façon limitée). J’ai eu l’occasion de mettre en place de la SOA sur des projets d’une volumétrie de 1.000 Jours/homme avec des gains certains en terme de réutilisabilité, de maintenabilité et de réactivité, ceci rien qu’au sein même du projet.

Deux approches peuvent être envisagées pour mettre en place une SOA : une approche top-down, et dans ce cas la mise en place se fait "par le haut" (par le top management) et une approche bottom-up qui part d’un ou plusieurs projets pilotes. C’est la démarche qui est généralement adoptée pour démarrer une organisation SOA. Cela permet de bien appréhender les concepts à mettre en place et d’adapter la démarche au contexte de l’entreprise. La création d’un premier ensemble de services, publiés selon une forme à définir (un wiki par exemple), permet à chacun de voir une offre de services se développer et au SOA de s’ancrer au sein de l’entreprise.

Quels sont les meilleures pratiques du domaine ?

Il faut penser services encore services et toujours services. Quand on est à un niveau business cela peut paraître simple, mais quand on descend dans les couches d’une application ce n’est pas toujours évident dans la mesure où le développement se pense d’abord en terme d’objets. C’est pourquoi il est nécessaire de développer le travail en amont (de design) en équipe, avec plusieurs acteurs dont l’un au moins a une forte connaissance du métier. Enfin, la définition d’un vocabulaire, de règles de fonctionnement, de contrat et de cycle de vie des services est nécessaire pour tirer une pleine efficacité d’une SOA.

Quelle satisfaction retirez-vous d'une approche SOA ? Et vos clients?

Grâce à des notions et un vocabulaire communs, il y a moins de cloisonnement au sein des différentes équipes. La motivation des équipes est aussi plus forte parce que tout le monde travaille dans un but de réutilisabilité et d’interconnexion. Cela est vrai pour les équipes de développement, mais aussi entre les projets et pour le business. Côté client, le métier apparaît beaucoup plus clairement au travers des services et vise un accroissement de la durée de vie des projets (un des objectifs majeurs du SOA). De plus, cela permet de mieux s’assurer de la validité des spécifications fournies par le business et de leur compréhension par les équipes de développement. Enfin, la définition de services de granularités différentes a des impacts sur les scénarios de tests qui permettent d’accroître la qualité des livrables. Comme c’est souvent le cas dans une démarche d’urbanisation, la complexité du SI est mieux gérée et fait souvent émerger des incohérences et des améliorations possibles à travers, par exemple, de la rationalisation.

Peut-on parler d'effets pour les utilisateurs finaux ? Et pour les équipes clients?

Du côté utilisateurs finaux et équipes clients, les effets se traduisent essentiellement en amélioration de la réactivité des équipes projets ainsi qu’en accroissement de la valeur apportée par les technologies de l’information aux métiers de l’entreprise.

Comment cela contribue-t-il au développement des équipes ?

Dans l’approche traditionnelle, le développeur est l’architecte, souvent solitaire, du cas d’utilisation qui lui est confié. Dans une architecture orientée service, une partie des interfaces qu’il aura à fournir sera définie par un groupe (dont il fait partie) et seront ensuite publiées et offertes aux autres acteurs qui pourraient en avoir besoin. De plus, il aura aussi à se poser la question si les fonctionnalités qu’il a à implémenter ne sont pas déjà fournies par d’autres services. Pour en arriver là, je préconise de distinguer deux niveaux de service : les services de composition (plus business) et les services unitaires (plus techniques), les premiers s’appuyant sur les seconds. Cela est relativement nouveau puisque auparavant la réutilisation n’était pas formellement gérée. Au-delà du fait que cela revalorise l’activité de développeur, cela entraîne un travail d’équipe plus motivant et une prépondérance du modèle des services sur la structure de l’ensemble, ce qui donne un résultat plus propre et plus satisfaisant pour l’ensemble des acteurs. La maintenance et surtout l’évolutivité s’en ressent d’ailleurs considérablement. Enfin, la définition d’un vocabulaire commun améliore la communication et le partage des compétences. Il y a moins de cloisonnement entre le business et le technique.

Pouvez-vous quantifier l'apport / les gains / les économies ?

Comme toute nouvelle technologie ou organisation, il y a un coût de mise en place qui va ralentir le lancement du ou des premiers projets pilotes. Puis l’accoutumance des différents acteurs à la nouvelle organisation, au vocabulaire et aux concepts, l’amélioration de la communication entre les différentes fonctions (business, architecte, développeur) puis la publication, la réutilisabilité et la composition des services va permettre d’augmenter la vitesse des développements techniques ou business. En fait, la mise en place d’une SOA impacte toute la chaîne de développement, depuis le business jusqu’aux tests. Le gain d’une SOA ne doit donc pas se chiffrer en terme de réutilisabilité mais d’abord et surtout en accroissement de la réactivité et d’ouverture du système. Dans un monde où le time-to-market se doit d’être toujours réduit pour faire face à la globalisation ou à la concurrence, on se rend compte de l’intérêt d’avoir de tels gains.

En effet, toutes les grandes banques actuelles ont démarré des processus d’urbanisation basées sur les architectures orientées services (SGCIB, CALYON, BNP…), des assurances aussi ont lancé des démarches, aujourd’hui déjà bien avancées, dans cette direction (comme SMA-BTP…) ou encore les télécoms (comme Bouygues Télécom). En conclusion, la question n’est pas de savoir si l’on doit passer aux architectures orientées services, mais quand et comment.

Y-a-t-il des écueils à éviter ?

D’un point de vue organisationnel, il faut bien voir que l’intérêt d’une SOA ne sera pas immédiat et que c’est un travail qui réclame du temps. C’est pourquoi il faut une volonté forte des sponsors et des leaders pour mettre cette démarche en place.

L’identification et la granularité des services constituent deux des aspects difficiles de cette approche. Si la granularité est trop forte il n’y a pas de réutilisabilité et de lisibilité et si la granularité est trop faible, la réutilisabilité passe par la composition d’une multitude de services qui accroît de façon excessive la complexité du système. De plus, il faut bien distinguer les services business des services techniques. Les deux peuvent être adressés par le SOA, il faut savoir ce que l’on veut exposer et à qui. Il est important aussi de trouver des personnes capables de travailler en équipe, capables de se remettre en cause et d’adopter un vocabulaire et des notions communes. Cela devient même un critère de recrutement en plus des compétences techniques. Enfin, la SOA requiert un effort qui doit porter sur la durée et c’est pourquoi les équipes doivent être motivées et adhérer à cette démarche.

En quelle mesure cela change les relations durant le projet ?

Il va y avoir clairement une meilleure adéquation entre les volontés du business et la réalisation par les équipes projets. Le fait qu’il y ait un décloisonnement entre le business et les équipes projets, ainsi qu’entre les différentes équipes elles-mêmes, change la nature des rapports entre les différents protagonistes. C’est pourquoi, à terme, la réactivité de l’ensemble des équipes s’améliore grâce à une communication plus directe entre les différents acteurs impliqués dans un projet.

Télétravail et informatique à temps partagé autour de l'AS400: un retour d'expérience

Face aux besoins temporaires de compétences, l'appel au temps partagé est une pratique considérée comme une dynamique novatrice pour le développement des entreprises. Son objectif étant de répondre aux contraintes de fonctionnement de l’entreprise et de permettre à celle-ci de faire face aux exigences de son activité et de son marché. Plus spécifiquement, dans le domaine de l'informatique, selon le Centre d'Innovation par les Technologies de l'Information, le partage d'informaticiens répond a un réel besoin des PME.

H-Urban vous présente aujourd'hui le retour d'expérience de Cogest, société « pionnière » dans le développement sur AS400 à temps partagé, en télétravail. En deuxième partie, nous présentons également le témoignage d'un de ses clients.

Point de vue Prestataire - Cogest

Présentez-nous en quelques mots sur votre société et vos activités à temps partagé en télétravail.

Depuis 10 ans, nous avons développé des activités de « service informatique à temps partagé » qui nous permettent de tenir le rôle de « l’informaticien » d’entreprise de façon externalisée. Depuis quelques temps, nous avons étendu ce rôle vers le télétravail pour les prestations de développement, de manière à compléter notre suivi sur site.

Comment est-ce que vos clients vous approchent, à ce sujet? Quel est leur profil?

Nos clients sont des PME et quelques administrations, pour la plupart équipés de serveurs iSeries. Nos clients souhaitent un suivi régulier sur site tout en recherchant des prestations de développement sur AS/400 ( ou autres plate-formes) en optimisant leurs coûts.

Comment répondez-vous à leurs besoins?

Nous établissons une fréquence d’intervention sur site la plus légère possible afin d’effectuer les transferts de compétences nécessaires et pouvoir travailler en équipe sur les différentes analyses. Ensuite nous travaillons à distance directement chez le client par connexion VPN.

Avec votre retour d'expérience, quelle serait la meilleure marche à suivre pour une entreprise qui souhaite se faire accompagnée à temps partagé?

L’idéal pour le client est de définir au mieux la fréquence d’intervention sur site et ensuite de bien veiller à formuler ses besoins.

Est-ce que vos clients peuvent identifier des gains qualitatifs et/ou quantitatifs?

Oui, la méthode leur permet de maîtriser au mieux leurs coûts. En effet, les séances de travail sur site nous permettent de définir d’un commun accord les temps nécessaire à chaque réalisation. Nous mettons à la disposition de nos clients des outils extranet nécessaires au contrôle des coûts et de l’efficacité de nos prestations (plannings d’intervention, comptes rendus, actions à prévoir …). Chacun peut donc apprécier au plus près le rapport qualité/prix de cette formule dans la transparence et le dialogue constant.

Pouvez-vous identifier des points particulièrement significatifs pour ce type de démarche?

Nous pensons être dans une certaine mesure une alternative à la décentralisation « offshore » de certains projets. En effet, pour des projets de petites et moyennes durée, nous offrons un minimum de présence sur site tout en effectuant la majorité des travaux en mode « télétravail ». Notre implantation provinciale nous permet alors de faire profiter à certains de nos clients parisiens de tarif très concurrentiels.

Pouvez-vous nous faire part de quelques retours client?

Un de nos client « historique » et régional, fournisseur de pièces forgées pour l'industrie de l'automobile, a opté depuis plus de 5 ans pour notre formule. La solidité de notre relation parle d'elle même.

Point de vue Client

Dans le cas de votre entreprise, pourquoi avez-vous fait le choix de l'informatique à temps partagé?

Nos besoins en terme de développement spécifiques devenaient plus importants et notre budget de fonctionnement ne nous autorisait pas plus d’une embauche à temps partiel. Nous ne sommes pas parvenus à recruter le profil qui nous intéressait en ne proposant au mieux qu’un mi-temps.

Quel domaine de votre informatique est le plus concerné?

Nous confions à la société COGEST la réalisation de projets spécifiques sur notre plateforme Iseries (Programmation RPGIV & SQL) autour de notre base de données DB2.

Comment est-ce que vous avez approché votre prestataire, à ce sujet? Pouvez-vous nous décrire les états « avant » et « après »?

Nous avions de plus en plus de difficulté en interne pour faire face aux demandes variables de nos utilisateurs. Le fait d’externaliser est aussi un moyen de disposer de compétences qu’il serait difficile de mettre en place en interne. Avant, nous avions du mal à fixer des délais à nos utilisateurs pour leur livrer les développements demandés. Maintenant, l’aide régulière que nous apporte COGEST nous permet de nous engager plus sereinement auprès des demandeurs.

Est-ce que les résultats correspondent à vos attentes?

Nous bénéficions d'une présence sur site indispensable mais minimum de COGEST pour travailler sur l’élaboration de nos demandes et réceptionner les travaux. Nous n’avons aucun équipement à leur mettre à disposition car l’essentiel de leurs réalisations sont effectuées à partir de leurs locaux grâce à une connexion VPN qu’ils nous ont paramétrée. Les travaux sont réalisés avec la même efficacité que sur site et en respectant nos procédures de tests et de mise en production.

Est-ce que des gains qualitatifs et/ou quantitatifs ont pu être identifiés, après la mise en place?

La méthode de délégation du travail à distance nous oblige à un formalisme très bénéfique qui nous permet de mieux formuler nos demandes et donc d’être plus efficace dans l’élaboration de nos dossiers. De plus le coût de chaque réalisation est connu et nous permet de valoriser l’intérêt de tel ou tel développement.

Pouvez-vous nous citer des exemples chiffrés?

Il est difficile d’entrer dans le détail des différents projets confiés, mais nous estimons que le « télétravail » confié à COGEST (70j/an soit environ 6j/mois) nous coûte l’équivalent d’un demi-salaire par an. L'avantage principal réside dans le fait que nous profitons d'experts différents en fonction de nos besoins, ce qui pour une PME/PMI est source de meilleure productivité dans un univers qui se complexifie plus vite que nos budgets augmentent.

Avez-vous des conseils à l'attention des entreprises qui souhaitent suivre votre démarche?

Le plus difficile est simplement de se laisser convaincre d’essayer sur quelques besoins spécifiques. Ensuite la formule s’impose d’elle-même.