Le Blog Faciliware

Innover en Communication et Collaboration / Lotusphere 2007: décryptage des tendances par Trilog Group

Bonjour, monsieur Alex El Homsi, nous vous remercions pour votre présence sur le blog Faciliware. Avant de commencer, nous rappelons à nos lecteurs que vous êtes le PDG de Trilog Group, société américaine éditrice de ProjExec®, une solution innovante de gestion des projet collaboratifs. Au mois de juin 2006, à l'occasion du lancement de ProjExec® en France, vous êtes intervenu sur notre Blog avec un article très intéressant et très plébiscité par nos lecteurs. En fin janvier, votre société, Trilog Group, a participé (et sponsorisé) la conférence Lotusphere d'Orlando, aux Etats-Unis: aujourd'hui vous décriptez les nouvelles tendances, à votre retour en Europe.

Comment avez-vous vécu cette manifestation, en 2007?

Tous les participants à Lotusphere 2007 ont été très impressionnés par l'accent mis par IBM sur les technologies et la marque Lotus, avec - comme point central - Notes et Domino. Dans le passé il y a eu des confusions sur le positionnement de Lotus par IBM mais cette fois cela n'a plus été le cas! L'époque Workplace appartient désormais au passé et désormais il est clair que l'avenir appartient à Notes et Domino - et c'est un message très bien accueilli par les clients et partenaires fidèles à Lotus depuis plusieurs années! D'ailleurs IBM a présenté une feuille de route très précise des technologies Lotus, ce qui a beaucoup rassuré le public Lotus.

IBM Lotus a présenté en détail la vision et le développement de sa plate-forme "Communication et Collaboration Unifiée" (Unified Communications and Collaboration, UC2) destinée aux entreprises innovantes et agiles, permettant aux utilisateurs de chercher, cibler et collaborer avec les experts. ProjExec® est parfaitement positionné dans cette stratégie emérgeante, puisque notre solution permet aux utilisateurs de communiquer et collaborer en temps réel, partout dans le monde et dans le contexte des projets auxquels ils sont impliqués.

Conscient des tendances du marché, orientées communication et collaboration, IBM Lotus met en phase le développement de ses futurs produits dans une nouvelle génération de solutions capables de répondre à ces besoins.

En cohérence avec sa stratégie UC2, IBM a annoncé que Domino 8 supporte les applications à base de composants en désignant Lotus Component Designer en tant que plate-forme de développement de ces applications. IBM a également présenté Lotus QuickR, la prochaine génération de Quickplace, ainsi que Lotus Connections, une nouvelle approche des activités orientés collaboration. Je précise que QuickR et Connections sont conçus justement pour répondre aux nouveaux besoins exigeant des logiciels de réseaux sociaux pour le monde de l'entreprise, disposant des fonctionnalités intégrées de partage des favoris, d'utilisation des profils métier, des modèles de blogs et wiki.

Quelles sont les nouveautés présentées par Trilog Group à cette occasion?

Les annonces de Trilog, ainsi que notre Démo Produit ont été exactement dans la lignée des dernières annonces IBM Lotus. Nous avons donc annoncé ProjExec® Components, des composants développés à l'aide de Lotus Component Designer. Les composants Trilog sont utilisés à leur tour par Lotus Component Designer pour le développement d'autres composants qui peuvent être assemblés dans des applications. ProjExec® est une telle application composite qui bénéficie des meilleures des technologies collaboratives de Lotus. Puisque nos composants ProjExec® Components sont développés sous Lotus Component Designer, ils pourront être intégrés dans les offres de portail Lotus - c'est le cas de QuickR et Lotus Connections.

Au fait, ProjExec® a été la seule solution ayant démontré durant Lotusphere 2007, lors des Démos Produits, sa parfaite intégration dans Lotus QuickR et Lotus Component Designer.

L'autre annonce majeure de Trilog concerne ProjExec® Online aux Etats-Unis, pour l'instant. Nous avons présenté notre offre de type Software as a Service (SaaS) en architecture hébergée, permettant l'utilisation immédiate de ProjExec® en mode ASP. Il s'agit d'une architecture plurielle, permettant aux plusieurs comptes de disposer de plusieurs sites administrés d'une manière centralisée, les ressource matérielles pouvant être partagées efficacement par plusieurs services pouvant ainsi optimiser leur infrastructure et dons leurs coûts.

Au-déla de l'intérêt de cet évènement pour les éditeurs / intégrateurs de logiciel, nous pensons surtout aux entreprises et aux utilisateurs finaux, non-informaticiens. Dans ce cadre, s'il y avait une seule chose à retenir après Lotusphere 2007, sur quel domaine se porterait votre choix?

Je penserais surtout à l'immense potentiel des applications composites pour la collaboration, autour de la plate-forme UC2. La possibilité de développer rapidement des telles applications est à mon sens le sujet le plus important! C'est ce qui permettra des évolutions importantes des applications existantes. Par exemple l'extension de QuickR avec des fonctionnalités de gestion de projet - et c'est justement ce que nous avons démontré à Lotusphere.

Dans le domaine de la gestion de projet, comment voyez-vous l'avenir?

Trilog est une des premières entreprises ayant décelé un besoin de gestion de projet intégrée à la collaboration, et un des premiers éditeurs ayant mis à disposition du marché d'une solution capable de répondre à ce besoin. Trilog est également le premier partenaire IBM ayant aligné ses produits avec la feuille de route d'IBM dans le domaine de la communication et collaboration, en s'intégrant aux produits comme Lotus QuickR et Lotus Component Designer. Nous continuerons à utiliser le meilleur des technologies collaboratives d'IBM Lotus afin de produire de la valeur ajoutée pour la collaboration et la gestion des projets des entreprises.

En ce qui concerne ProjExec®, que pouvez-vous anticiper pour nos lecteurs?

ProjExec® suivra très attentivement la feuille de route des technologies IBM Lotus. Trilog Group compte enrichir et renouveler les éléments clé de sa ligne de produits, y compris ProjExec Online, ProjExec Components ainsi que l'intégration avec Lotus QuickR. En utilisant Lotus Component Designer, nous continuerons la mise à disposition de nos composants dans IBM WebSphere Portal, Lotus QuickR et Lotus Connections.
Puisque le serveur portail intégré dans la version 8 de Domino lui permet de se présenter comme une plate-forme d'applications composites, nous comptons de fournir des applications Domino 8 à base des composants développés sous Lotus Component Designer.

Nous présenterons très prochainement tout ceci à l'occasion des Tendances Logicielles Printemps 2007, le 27 mars au CNIT de La Défense, ainsi que durant les rencontres du Management Projet 2007, le 26, 27 et 28 mars, toujours au CNIT, nous sommes à vos dispositions pour vous répondre.

Pour des détails, nous invitons nos lecteurs à nous contacter par e-mail.

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.

Conformité et Gouvernance - témoignage expert

Bonjour, Ann Dushane, vous intervenez aujourd'hui sur notre Blog Faciliware pour nous faire part de votre expertise dans le domaine de l'Audit interne SI. Tout d'abord, présentez-nous en quelques mots votre société.

Control Solutions est le premier fournisseur global en services d’audit interne, conformité, gestion des risques et solutions technologiques. Depuis plus de 15 ans, plus de 500 entreprises publiques, privées, ONG et administrations ont choisi de faire confiance à Control Solutions.

Avec plus de 800 consultants travaillant dans 25 bureaux, Control Solutions assure à ses clients une présence en Europe, Amérique du Nord et du Sud ainsi qu’en Asie Pacifique.

Nos activités se répartissent en quatre pôles : Audit Interne, Conformité réglementaire, financière et éthique, Gestion des risques, Technologie.

Voulez-vous nous dire quelques mots sur vous-même? Quelles sont vos fonctions, quel a été votre parcours, quelles sont vos responsabilités?

Senior Manager d’audit interne des Systèmes d’Informations, je travaille chez Control Solutions depuis 2005 aux Etats-Unis et en France. J’ai 10 années d’expérience en tant que Chef de Projet dans différents domaines informatiques. Ma formation est constituée d’un MBA à Thunderbird, the Garvin School of International Management et d’une Maîtrise de Sciences Economiques et français de l’Université de Pennsylvanie. Pendant mon activité de Chef de Projet au sein d’une compagnie pétrolière en 2004, j’ai géré la phase du retest de la première année du projet de conformité avec la loi Sarbanes Oxley. C’est grâce à cette expérience que j’ai rejoint Control Solutions pour un poste d’IT Audit Manager.

Quelles sont les spécificités sectorielles ou géographiques de la conformité?

Toute société cotée sur un marché américain (NYSE, Nasdaq …) est impactée par la loi Sarbanes Oxley (SOX ou Sarbox). Cette loi n’est pas réservée à certains secteurs d’activité, elle touche tous les secteurs. La loi s’est d’abord appliquée aux plus grandes sociétés américaines en 2004. Après deux années d’application des normes SOX, on constate une stabilisation et une pérennisation des contrôles mis en œuvre par ces sociétés. Elles s'attellent désormais à passer dans un mode de contrôle continu, c’est-à-dire une automatisation du test des contrôles en question. Les sociétés cotées de taille moyenne et petite (appelées les « non-accelerated filers ») ont gagné un délai de conformité passant de la fin d’année fiscale du 15 juin 2007 au 15 décembre 2007.

Pour les « foreign private issuers », telles que les sociétés françaises cotées aux Etats-Unis, on voit une augmentation très nette de l’activité associée à la conformité depuis cette année, activité intense qui se poursuivra très clairement en 2007. Les grandes sociétés non américaines qui déposent un dossier 20-F ou 40-F auprès des autorités boursières américaines – pour leur cotation sur un marché américain – doivent être en conformité dès le 15 juillet 2006 ou à la fin du premier exercice clos à partir de cette date. Les « foreign private issuers » qui sont considérés comme des « non-accelerated filers » ont gagné un délai d’un an, ce qui les amène à une date de conformité au 15 juillet 2007 ou à la fin du premier exercice clos à partir de cette date.

Comment est-ce que vos clients vous approchent, à ce sujet? Décrivez-nous, le cas échéant, leur profil-type.

On observe deux types d’attitudes complètement opposées chez nos clients vis-à-vis de la loi. Le premier consiste à se mettre en ordre de marche pour réussir sa mise en conformité dans les délais impartis. L’autre attitude consiste à très peu travailler sur ce projet en attendant des évolutions favorables de la loi (voire en espérant être finalement exclu de son champ d’application). Cette deuxième attitude peut conduire à des situations d’extrême urgence si l’évolution de la loi n’est pas celle escomptée.

Il est par ailleurs fréquent que les sociétés sous-estiment la charge de travail associée à leur processus de conformité.

C’est souvent ce type de société qui sollicite notre accompagnement sur leur projet.

Notre expérience nous a montré que pour bien préparer la conformité à la loi, il faut à peu près un an voire plus pour certaines sociétés très décentralisées. Si des sociétés ont des politiques et procédures rigoureuses en place et un environnement de contrôle bien établi, il est possible de prendre un peu de retard, mais la plupart des sociétés n’ont pas les pratiques nécessaires de contrôle en place. La définition de procédures adaptées prend beaucoup de temps. Par ailleurs, la conformité passe par une phase d’évaluation des contrôles mis en place, phase qui doit prouver leur bon fonctionnement (en plus de leur simple existence). Cette phase peut être très lourde à gérer de manière interne et il est fréquent que nos clients nous demande d’en réaliser tout ou partie pour eux.

Comment répondez-vous à leurs besoins?

Un projet de ce type là – tout comme un audit interne – est une tâche qui se superpose à l’activité quotidienne de l’entreprise. Sa complexité et la charge qu’elle nécessite lui confèrent donc un caractère disruptif fort pour l’activité de l’entreprise. Notre philosophie consiste donc à tout mettre en œuvre pour rendre notre intervention la moins perturbante possible pour nos clients et pour les opérationnels avec lesquels nous sommes en interaction. De fait, nous pouvons apporter notre méthodologie et nos process et prendre en charge de A à Z un projet de conformité ou simplement nous inscrire dans un projet déjà en route et mobiliser notre expertise afin de réaliser les tâches nécessaires plus rapidement que nos clients et surtout éviter à avoir à reprendre des tâches déjà réalisées parce que leur objectif n’était pas bien défini : ça coûte trop cher ! Notre expérience de la conformité SOX nous permet de connaître les exigences de la norme dès le début du projet.

Nous sommes le partenaire de nos clients pour les aider à préparer leur audit externe par les commissaires aux comptes. Ceci implique d’identifier les éventuelles déficiences dans leurs process et de proposer des solutions pour y remédier.

Avec votre retour d'expérience, quelles seraient les« meilleures pratiques » pour une démarche de gestion des risques ?

Une Gestion des Risques saine doit combiner une approche « top-down » et une approche « bottom-up ». La première étape consiste bien sûr à identifier les risques que la société souhaite traiter. Certains risques peuvent être identifiés mais non-traités dans le cas, par exemple, ou leur résolution coûterait plus cher à l’entreprise que la survenance du risque lui-même. Une fois les process associés aux risques identifiés, il faut les documenter afin de les clarifier et assurer une information uniforme pour tous les acteurs du process. Enfin, pour s’assurer que les acteurs suivent les procédures, il faut contrôler périodiquement l’activité. La loi Sarbanes Oxley met en place un contrôle systématique qui, avant, pouvait être plus occasionnel.

Du côté des Systèmes d’Information, beaucoup de sociétés ont notamment du mal à contrôler leurs droits d’accès. La plupart du temps, elles n’ont pas de procédures pour gérer les modifications de droits, ni, dans une moindre mesure, les créations et suppressions de droits liées aux entrées et sorties de personnel. De fait, elles ne peuvent pas fournir de preuve que les accès ont été autorisés ou même demandés. En outre, les bases d’utilisateurs sont rarement revues, ce qui fait qu’il peut y avoir des comptes inactifs depuis plusieurs années.

D’autre part, au niveau du développement et du changement d’applications financières, plus de trois quarts de nos clients n’ont pas de contrôles nécessaires pour assurer la couverture de risque de fraude dans les applications. Les changements ne sont que peu ou pas du tout documentés. Par ailleurs, il n’y a très souvent pas de preuve que les changements ont été testés et un manque de séparation de tâches entre les environnements de développement et de production est constaté aussi.

Deux thèmes récurrents dans la loi SOX sont la documentation et la preuve des contrôles. Classiquement, chez un client qui se prépare à la conformité à SOX en première année, on constate un manque des deux. Il y a bien sur d’autres contrôles qui manquent également, mais ces deux éléments fondamentaux sont rarement en place à 100% chez nos clients.

Hormis les aspects réglementaires, est-ce que des gains qualitatifs et/ou quantitatifs peuvent être identifiés, après la mise en place d'une démarche de conformité?

C’est vrai que la loi Sarbanes Oxley est souvent critiquée pour son coût de mise en place. Néanmoins, on peut lui trouver des aspects positifs. Tout d’abord, une réduction importante du risque de fraude. En effet, grâce au processus de gestion des habilitations, les sociétés peuvent réduire le nombre de licences achetées car elles auront une idée précise du nombre d’utilisateurs d’un logiciel ou d’un progiciel.

Elle peut aussi générer des gains de temps. A titre d’exemple, un de mes clients n’avait aucun moyen pour suivre ses demandes d’interventions. Elles arrivaient par téléphone, par email, par écrit ou simplement lorsqu’un demandeur passait dans le bureau du Responsable des SI. SOX impose notamment le suivi des demandes d’intervention. N’ayant pas le budget pour acheter un logiciel de suivi de demandes, il a mis en place un système basé sur des outils bureautiques grand public. Ainsi, il a créé un canal unique de demande d’intervention sous formes d’enregistrements dans une base de données. Cet outil lui a également permis d’avoir un meilleur suivi des affectations de ses équipes sur les demandes et une vision globale des types récurrents de problèmes informatiques rencontrés. Cette exigence de SOX lui a clairement permis de créer un process qui a amélioré l’efficience de son équipe.

Pouvez-vous identifier des points particulièrement significatifs pour ce type de projet?

Lorsque les sociétés pensent à la loi Sarbanes Oxley et à ses implications sur les systèmes d’information, elles ont tendance à croire que c’est une loi qui ne se focalise que sur la sécurité proprement dite. C’est vrai que celle-ci peut représenter plus que 50% des contrôles informatiques, mais la loi exige aussi des contrôles de gestion du changement, comme expliqué plus haut. Elle exige aussi des politiques et procédures de sauvegarde et de restauration des données ainsi que l’exploitation du SI. Si les sociétés utilisent des tierces parties pour l’exploitation ou l’hébergement de leurs données, il leur faut également avoir des contrôles en place pour gérer ces relations et les contrôles des tierces parties.

Les sociétés comme Control Solutions connaissent parfaitement les exigences de la loi Sarbanes Oxley. A ce jour, nous avons accompagné plus de 350 clients dans le monde entier sur leur conformité. Nous pouvons aider nos clients à traiter tous les sujets soulevés par SOX, ainsi qu’à trouver des moyens plus efficaces pour s’assurer que les procédures mises en place seront pérennes indépendamment de l’objectif de conformité réglementaire. La conformité à la loi SOX est aujourd’hui perçue comme un projet, néanmoins il est essentiel d’être capable de la gérer sur la durée. C’est un enjeu extrêmement fort de notre intervention.

English version