mercredi 29 février 2012

La gestion de projets permet d'éviter les stratégies mobiles fragmentées

Par L'Atelier - San Francisco 29 février 2012 figurines isolées sur des pièces de puzzle éparpillées
Les entreprises luttent pour répondre aux exigences de la stratégie mobile. Mais la lenteur du suivi des projets et des plans d'approche poussifs rendent la progression trop lente au goût d'IT.
Les investissements dans les canaux mobiles augmentent pour toutes les entreprises, quel que soit leur type ou leur taille, comme le mentionne le Mobile Business Forecast 2012 d'Antenna. Pour les 18 prochains mois, les entreprises aux États-Unis et au Royaume-Uni prévoient des investissements atteignant en moyenne 422K USD jusqu'à 926K USD, et un tiers a l'intention de lancer quatre projets mobiles, voire plus, dans les 12 à 18 mois.  Mais, en moyenne, ces entreprises travaillent avec trois fournisseurs différents de solutions mobiles en même temps à cause de l'incapacité de ceux-ci de répondre à plusieurs aspects de la chaîne des valeurs mobile. Eugene Signorini, Senior Vice President of Research pour le Yankee Group explique : « La question qui se pose aujourd'hui est de savoir comment les entreprises saisissent les opportunités offertes par la mobilité tout en maintenant leur contrôle et leur visibilité. Aujourd'hui, une entreprise doit englober l'entièreté de l'expérience mobile et,  en matière de mobilité des entreprises, appliquer une approche intégrée, unique, visant à satisfaire tout autant les employés que les clients et à générer revenus et croissance. »
La stratégie mobile doit être accompagnée d’une gestion de projet efficace
Le rapport montre que les entreprises affectent des ressources à trop de projets simultanés : les fournisseurs de solutions mobiles sont, le plus souvent, de petites entreprises spécialisées, et les marques doivent soutenir de multiples projets répondant à des bouts de stratégie, au coup par coup. En se lançant dans un développement simultané, elles risquent de voir leur stratégie mobile se fragmenter, du fait de l'implémentation de technologie redondante, de sorte que le projet devient difficile à gérer. Les project managers sont essentiels dans ce processus afin de trouver un équilibre entre les pressions des chefs de département et celles d'IT, entre rapidité et efficacité et due diligence et protection des données. « La technologie mobile a modifié la façon dont les gens interagissent et les implications pour les entreprises sont tout aussi importantes » ajoute Eugene Signorini.
Les cadres confrontés à la lenteur d'implémentation des strategies
Cette recherche d'équilibre et cette approche projet exigent du temps. Les tendances mobiles et les limites de certaines entreprises ont contribué à la frustration de certains CIO et CTO. Selon l'étude, « 45% d'IT et des décideurs d'entreprise du Royaume-Uni et des États-Unis ne sont pas satisfaits de la lenteur avec laquelle les projets mobiles qu'ils parrainent arrivent sur le marché. » Un peu moins sont également insatisfaits du coût des solutions mises en place. En moyenne, les entreprises ont besoin de plus de six mois pour finaliser leurs projets, et 10% prennent même un an, voire plus. Ces problèmes montrent qu'il y a une marge de croissance dans les produits mobiles rapidement créés, et de grande qualité, et une possibilité d'améliorer le manque de transparence des prix pratiqués par les fournisseurs de solutions. Quant aux entreprises, elles doivent consacrer plus de temps à préparer la mobilisation avant d'acquérir des solutions.

10 questions non-techie managers should ask about IT projects

Takeaway: Business managers may lack the tech knowledge to make sure a project is on the right track. Here’s what they should be asking IT to improve the odds of project success.
If you are a non-techie responsible for a project that involves developing or enhancing software, it can be hard to ask the right questions. It is critical, though, to stay engaged in the software development process and to keep the communication flowing — this greatly improves the likelihood of a successful project. Below are 10 questions that non-technical project stakeholders should ask their techie counterparts.

1: What’s the best way to communicate with the technical resources?

This is a question you can ask an IT manager. Maybe there is a business analyst or project manager from IT assigned to coordinate and communicate with your techies. But if there isn’t, that task may fall to you. Some techies will be much better at understanding your “business needs” than others. Make sure that the requirements are written down and that you read them (even if they are boring!). After you read them, go over them with your BA, PM, or techie. Even just paraphrasing each requirement can help avoid costly communication failures.

2: Can you show me what you’ve got so far? (Ask repeatedly)

The sooner you can provide feedback to your IT counterparts, the less costly it will be to make important course corrections. Let’s face it: It’s difficult to conceptualize how something like a piece of software will work based on written requirements. It’s only when you see it in action that you find all the things that weren’t mentioned or were, worse yet, just assumed. Ask to see the latest work — even if it is incomplete — so you can provide feedback. Maybe you will be providing feedback on a login page or a search screen that doesn’t do anything yet. It doesn’t matter. Get the team used to regularly showing you progress. Also, it never hurts if you’ve got donuts or bagels when you come around.

3: Are you waiting on me for anything?

Some projects will have a full-time project manager who will be keeping careful track of open issues. If you don’t have a resource supporting you like that, make sure you track open questions and issues carefully. It’s always a good idea to ask the techies if they’re still waiting for an answer from you on something you missed.

4: How will this be tested?

A well-managed software development team will create a test strategy near the start of the project. Understand what that strategy is and ask questions if it doesn’t make sense to you.

5: When can I help with testing?

Make sure that you or your users play an integral role in testing. That role may be to help develop test cases or it may be to test, hands-on. Ideally, it is both. Be sure that representatives from the business side are playing an active role in testing. They will have a better intuitive understanding of what is “right” than full-time QA folks who need to rely on test-scripts.

6: How does this system or change affect our other systems?

In a company with lots of systems that interact with each other, it can be difficult — for business users and techies alike — to identify how a change will affect other systems. As a business stakeholder, you should dedicate some time to thinking through how the project affects other downstream processes. You should also have a focused discussion with your technical counterparts on where the new or modified system touches other systems. If your project affects other systems, make sure they’re considered in the test strategy you asked about two questions ago.

7: What does the system do when something goes wrong?

Unfortunately, things will go wrong. All well-designed systems should be designed to handle errors as gracefully as possible. Ask this question to verify that your system is being designed this way. Answers like “I don’t know” or “They will get some kind of exception message” aren’t good. Good answers will include an explanation of how the user and support staff will be notified in a way that makes sense; how bad or incomplete data will be prevented from going into the system; and how the process can be restarted after the error.

8: Can you show me the audit trail?

Most business users assume that all computer systems keep great records of what everyone has done on the system and all the history of changes and transactions. In general, none of this happens unless the people who developed the system thought to add those features. If these features are important to you (and I have seldom seen a business system where audit trails weren’t important), make sure that they are part of the requirements and ask for a demonstration.

9: What happens when you are done?

Many projects risk falling apart during the handoff from the technologists to the business. Make sure there is a clear plan for what happens when the programming and testing are done. You may be focusing on a training plan or customer communication strategy, but you need to make sure the technical team has a solid plan for moving the system into production and transitioning from development to operations. This should include establishing who supports the system going forward as well as mundane issues, such as making sure backups are in place. Also, you know there are going to be some changes needed after the first release. Make sure the technical resources are available for those inevitable adjustments.

10: What do you think?

There are plenty of techies who aren’t afraid to speak their mind about any number of subjects (regardless of whether they have an informed opinion). However, there are also plenty who really understand what the business is trying to achieve but are reticent about expressing their ideas. Ask them their opinions — you may gain some valuable insights.
Good technologists — such as the ones on my team — will bring up these questions themselves. But it never hurts to make sure. Take the time to ask these questions and any others you can think of. Use the project as an opportunity to expand your horizons a little and learn about how these systems work and are built. More than anything else, stay engaged in the project from start to finish. This will help ensure that you can ask the 11th question: “Where should we celebrate the successful completion of the project?”

http://www.techrepublic.com/blog/10things/10-questions-non-techie-managers-should-ask-about-it-projects/3078?tag=nl.e053

Les contrats pour le SaaS sont déjà prêts sur étagère, ce n'est pas le cas pour l'IaaS

Cécile Bottalla, DSI de la Mutuelle Générale

par Bertrand Lemaire et Thierry Lévi-Abégnoli


« Les contrats pour le SaaS sont déjà prêts sur étagère, ce n'est pas le cas pour l'IaaS » avertit Cécile Bottalla, DSI de la Mutuelle Générale.


(27/02/2012) - La Mutuelle Générale revendique 1,4 millions de personnes protégées par ses assurances en santé et prévoyance, tant sur le marché des particuliers que sur celui des entreprises. Dans le cadre de la refonte d'applications, elle a opté pour des applicatifs en mode SaaS ou des hébergements en IaaS. Un tel choix facilite également les évolutions sans à-coups ni surcoûts.

Elle disposait ainsi d'une messagerie obsolète sous Lotus Notes. Au moment d'en changer, elle a choisi de migrer vers une offre SaaS, en l'occurrence celle proposée par Microsoft, Office 365. Cette solution avait l'avantage d'éviter de devoir installer et gérer des serveurs avec des applicatifs. Le coût à l'utilisateur était, de plus, adapté à une refacturation aisée aux directions métiers.

La même problématique s'est posée et la même solution a été choisie pour la GRC (SaaS avec Salesforce) et pour le logiciel métier principal (IaaS chez Atos).

Ces solutions avaient l'avantage de régler du même coût la question du datacenter devenu trop étroit pour couvrir les besoins de l'entreprise. A terme, le datacenter interne disparaîtra quasi-totalement au profit de l'IaaS.

Parmi les obligations, la Mutuelle Générale insiste sur la nécessité d'être très attentif aux contrats. Ceux-ci sont standardisés pour le SaaS, nettement moins pour l'IaaS (et donc plus complexes à conclure). Cette question a pris une dizaine de mois.

Cécile Bottalla, DSI de la Mutuelle Générale, conteste aussi l'idée reçu que le choix du cloud fait disparaître les informaticiens des DSI. Les architectes tant d'infrastructures que d'applicatifs comme les gestionnaires de contrats demeurent, en particulier, indispensables.

Le bénéfice du cloud est avant tout financier mais aussi en qualité de service. Une grande qualité est ainsi accessible sans augmentation de budget voire par une division par deux des coûts.

L'interview complète en vidéo

http://www.cio-online.com/entretiens/lire-le-cloud-facilite-le-renouvellement-et-l-administration-des-applicatifs-430.html?utm_source=mail&utm_medium=email&utm_campaign=Newsletter

La modularité de la méthodologie – un facteur clé

Certaines organisations considèrent qu’une méthodologie de management de projet occasionne des frais inutiles. D’autres pensent qu’il s’agit  d’un « mal nécessaire ». Parallèlement à ces points de vue, TenStep considère qu’une méthodologie de management de projet représente une valeur ajoutée importante pour l’organisation. La section A1 explique comment cette valeur est ajoutée à l’organisation, et ce, à plusieurs niveaux.
Pourquoi certaines personnes et certains organismes considèrent-ils qu’une méthodologie de management de projet est un « mal nécessaire »? L’une des raisons les plus importantes réside dans le fait que la grande majorité des méthodes disponibles manquent de flexibilité et de souplesse. Ces méthodes sont conçues surtout pour faire face aux situations découlant des grands projets où on sent le besoin d’une démarche très structurée de tous les aspects du projet. Le problème est que d’autres types de projets sont censés suivre ces mêmes processus, sans tenir compte de leur envergure et de leur complexité.
Cela n’est pas logique. Pour qu’une méthodologie de management de projet soit efficace, elle doit permettre une application conforme aux caractéristiques de différents projets. Les grands projets nécessitent plus de rigueur et de structure que les petits projets. Nous devons le reconnaître. Habituellement, les problèmes de ces grands projets n’émanent pas d’une structure trop rigide; ils résultent plutôt de la situation des chefs de projets débordés en raison d’un manque de procédés adéquats. Ces chefs de projets, trop souvent, ne disposent pas de procédés de planification, d'estimation, de gestion de l’échéancier, de modifications, de risques, etc. Cela fait en sorte que les chefs de projets sont réactifs et confrontés en permanence à des situations d'urgence.
À l’opposé, les procédés rigoureux proposés par les méthodologies lourdes tendent à contrecarrer les petits projets. Ces projets peuvent être gérés avec des techniques et procédés légers et informels. L'échéancier, pour un petit projet, peut être élaboré selon une liste d’activités ou un tableur. Les petits projets ne sont généralement pas très risqués, de sorte qu'ils ne requièrent pas une gestion formelle des risques. En général, l’impact des problèmes des petits projets est relativement minime. Par exemple, si un projet de 100 heures se met à doubler en importance, cela n’aura probablement pas de conséquences graves au niveau de l'organisation exécutrice. Par contre, si un projet de 10.000 heures double en termes d’envergure, cela pourrait occasionner un impact majeur.
La méthodologie TenStep de management de projet a été conçue pour permettre une application à échelle extensible en accord avec la taille et la complexité de chaque projet. L'idée directrice de TenStep est d’appliquer à chaque projet le niveau optimal de gestion. Ce niveau optimal ne signifie pas automatiquement ni peu ni beaucoup de structure. Il implique qu’il faudra appliquer une approche très structurée pour les grands projets, tandis que pour les petits projets, le degré optimal de procédures de gestion de projet peut être très léger. Gardez à l’esprit cette philosophie à valeur ajoutée contenue dans la Méthodologie TenStep quand vous l’utilisez pour la gestion de votre projet.
Terminologie de management de projet
Durée de l'activité. Durée exprimée en unités calendaires entre le début et la fin d'une activité de l'échéancier. Voir aussi Durée.
Échéancier directeur. Échéancier récapitulatif du projet dans lequel sont identifiés les principaux livrables et éléments de la structure de découpage du projet, ainsi que les jalons clés de l'échéancier. Voir aussi Échéancier des jalons.
Abréviations courantes
LOE (anglais) : Level of Effort
       (français) : Niveau d'effort
Liens intéressants
Logiciel: Collabtive
·   Société: Collabtive, Saarbrüchen, Allemagne
·   Catégorie: Gestion de projet et collaboration basée sur le Web
·   Fonctionnalités:
o    Crée des profils d'utilisateurs pour tous les membres de l'équipe
o    Offre un système de gestion des autorisations basé sur les rôles
o    Transmet aux membres de l'équipe des messages et de nouvelles tâches par des fils RSS (syndication vraiment simple)
o    Permet aux utilisateurs de transférer des informations de journaux d'activité et de rapports


Les équipes de TenStep Francophone
TenStep Francophone

mardi 28 février 2012

À propos de gestion de données

La difficulté n'est plus d'accéder à l'information mais de trouver celle qu'il nous faut ! Serge Abiteboul, chercheur en sciences des données, nous l'explique dans cet épisode du podcast audio.
© Inria / Photo C. Lebedinsky
Face à la croissance exponentielle des données, les problèmes de stockage et de calcul étant en grande partie résolus, les spécialistes sont confrontés à un nouvel enjeu majeur : gérer la masse de données disponibles, notamment sur le Web.
Si l'on est aujourd'hui capable de développer des algorithmes toujours plus performants pour classer ou trier les informations dans les pages Web (voir par exemple Comment Google classe les pages Web), il reste encore beaucoup à faire pour mettre l'utilisateur au cœur de l'expérience de recherche d'information. Comme nous l'explique Serge Abiteboul, après avoir construit les réseaux de machines et les réseaux de contenus, il faut maintenant se lancer dans l'ère des réseaux d’utilisateurs, pour que les données produisent des connaissances.
Pour en savoir plus sur ce domaine de recherche, voir la leçon inaugurale de Serge Abiteboul, « Sciences des données, de la logique du premier ordre à la Toile », le 8 mars 2012 au Collège de France.
Écoutez l'interview en MP3 (durée : 12 min 51 s).


Pour l'écouter sur votre baladeur, téléchargez le fichier ou abonnez-vous au podcast d'Interstices.

http://interstices.info/jcms/int_63511/a-propos-de-gestion-de-donnees

Le cloud computing va piano dans les TPE / PME

L’adoption du cloud computing en entreprise a pris du retard. Les PME se montrent enclines à virtualiser leurs serveurs, mais les enjeux sécuritaires inhérents imposent un frein à la démarche.

La virtualisation des parcs informatiques en entreprise progresse à un rythme modéré. Au fait des enjeux sécuritaires que revêt l’adoption du cloud computing, les grands comptes se montrent plus frileux que les PME, elles-mêmes globalement réfractaires à la démarche.
Ainsi s’énoncent les conclusions d’une étude menée par le cabinet Ponemon, pour le compte d’Acronis, à l’appui des témoignages de quelque 6000 DSI de petites entreprises sondés dans 18 pays, essentiellement en Asie et Europe de l’Ouest, entre septembre et octobre 2011.

Evocateur, le constat reflète les heurts auxquels sont confrontés les prestataires de tels services d’hébergement à distance. La virtualisation des serveurs est certes en marche, mais elle affiche une progression moindre que celle escomptée.
En 2012, environ 29% des infrastructures de TPE / PME seront virtualisées (+21% en rapport au dernier baromètre annuel), loin des prédictions d’observateurs qui tablaient originellement sur un taux d’adoption de 33% à la fin 2011.
Ce taux d’adoption devrait s’afficher en hausse de 14% dans les grandes entreprises, significativement moins séduites, comme l’évoquait un peu plus tôt Gartner.
Dans 47% des cas, les usages qui en découleront se cantonneront pour tout ou partie à la sauvegarde de données. Un quart des sondés envisage d’y associer une déportation applicative et le recours à des solutions SaaS.
Le consensus s’accorde par ailleurs à encenser certains bienfaits de l’infonuagique, tout particulièrement la souplesse et la rapidité de déploiement (plébiscitées à 20%), mais aussi la baisse des coûts d’acquisition et de maintenance (18%).
Au rang des préoccupations qu’évoquent les directeurs techniques interrogés pour l’occasion, la disponibilité et l’extensibilité (scalability) de l’ensemble.
Subsiste toutefois une inconnue : la sécurité des données.
58% des DSI reconnaissent attacher trop peu d’importance à la sauvegarde des données. La virtualisation du stockage serait source de ce laxisme, effet pervers, alors que seules 24% des entreprises effectuent un back-up quotidien.
A cet instar, quand bien même 83% des PME ont déjà entrepris des démarches de délocalisation de leur parc informatique, les instances virtuelles n’en sont constitutives qu’à hauteur de 19%, aux antipodes de prévisions qui faisaient état d’un franchissement du seuil des 30% en 2011.
En cause, les multiples soupçons qui pèsent sur l’intégrité des fichiers (25% des Suédois s’en inquiètent, les Français sont 19%), notamment au vu du droit de regard que s’octroient les prestataires techniques, en vertu du Patriot Act.
Pour autant, moyennant la définition de politiques adéquates dans l’exercice de la sauvegarde et du contrôle des données, les entreprise se veulent optimistes : elle sont 50% à parier sur le cloud pour l’année 2012.

http://www.siliconcloud.fr/article/?post=51047&site=itespresso

Simplifying Application Performance Monitoring Webcast Series

Learn How the Essentials of Application Performance Monitoring Can Boost the Efficiency and Productivity of Your Organization

Virtually every organization relies on applications that are vital to the business and ensuring the availability and consistent performance of those applications has become a top priority. Having the right tools to simplify the process of managing applications is a critical requirement for success. Our webcast series explores the essential elements of application performance monitoring (APM) and shows you how your organization can adopt streamlined procedures for effective APM.

Application Performance through the Eyes of Your Customer

End-user experience is the point where the business and IT connect and communicate via a common language. While the impact of poor web application performance and the resulting user experience is immediate to the business, it's not always clear to IT. And traditional monitoring tools only add to the IT blind spot. To gain visibility and effectively communicate with the business, IT needs a user-centric perspective on managing the web application performance. This includes the ability to monitor transactions in real-time, playback user sessions and develop meaningful business and IT reports. This webcast will show you how to meet these objectives.
View now

Key methods for Managing Complex and Multi-Platform Database Environments

The rise of "big data" is overwhelming many database sites, not only due to sheer volume, but also with the proliferation of new types of databases. These are creating new headaches for the data professionals who manage them. This webcast explores key methods to successfully managing today's complex cross-platform database infrastructures. We'll discuss the challenges DBAs face and strategies to select the right tools to monitor and manage the database environment. We'll also discuss solutions to consolidate and standardize database performance and service across your environment, ensuring consistent coverage, reduced cost of ownership, and the ability to extend to a full APM solution.
View now

Pragmatic Steps for Successful Application Performance Monitoring

The rise of virtualization and cloud technology has added a significant challenge when it comes to performance monitoring in the IT environment. What are these challenges? And what is the best approach to solve them? This on-demand webcast will let you know! It outlines best practices to building an application-centric monitoring solution. Watch the webcast today and discover what you should monitor, a step-by-step approach for application monitoring, what to look for in an APM tool, and more.
View now

http://www.quest.com/landing/default.aspx?ID=6023&utm_campaign=33461-15425-AM-EMEA-Foglight_January_France&utm_medium=email&utm_source=Eloqua

L'« open source », une révolution


28/02 | 07:00 | Les Echos, DE BERTRAND DIARD
Il est intéressant de comparer la croissance et l'impact de l'objet le plus symbolique du XX e siècle, l'automobile, avec l'évolution actuelle de l'industrie du logiciel. Produit de 1908 à 1927 par Ford, le modèle T est considéré comme la première automobile abordable. Cette voiture était populaire, même si les clients n'avaient que peu de choix d'options. Elle était livrée avec un seul type de moteur et un nombre limité de styles de carrosserie. La fameuse règle d'Henry Ford : « N'importe quelle couleur pourvu qu'elle soit noire », a été mise en place en 1914 pour limiter les choix de couleur à une seule. A l'époque, on payait la voiture comptant et on obtenait ce pour quoi on avait payé. Point.
Le développement de la technologie automobile a ensuite été rapide, grâce à l'apparition de centaines de fabricants qui luttaient pour attirer l'attention des consommateurs. C'était le début d'une révolution industrielle internationale et d'une bataille entre constructeurs pour la domination du marché, qui est encore d'actualité. Conséquence de cette concurrence accrue et du penchant des clients pour l'innovation, les acheteurs ont désormais le choix parmi un large panel de marques et de modèles, pour trouver la voiture correspondant à leurs besoins.
La trajectoire de l'automobile n'est pas très différente de ce que nous avons vécu dans l'industrie du logiciel. Jusqu'aux années 1960, les ordinateurs - des « mainframes » énormes et coûteux -étaient loués plutôt qu'achetés. Le code source des logiciels était fourni et les clients qui achetaient du hardware aussi cher ne payaient pas en plus pour les logiciels. Mais, comme l'automobile, l'industrie du logiciel s'est développée grâce à des visionnaires comme Ford, qui travaillaient sur des prototypes dans leur garage.
Aujourd'hui, vous pouvez choisir entre des logiciels propriétaires ou « open source ». Vous pouvez déployer des logiciels libres ou des logiciels sous contrat de souscription annuelle. La façon de consommer des logiciels a évolué. Vous pouvez choisir d'installer le logiciel sur vos serveurs, de le déployer dans le « cloud » ou de l'utiliser en SaaS (« software as a service »).
Avant l'« open source », vous n'aviez pas d'autre choix que d'acheter des licences de logiciels propriétaires. Comme avec la Ford T, le client disposait de peu d'options. Avec la flexibilité et l'innovation qui le caractérisent, l'« open source » a fait évoluer les modes d'adoption et d'achat de logiciels par les entreprises, en offrant plus de choix. La principale raison pour laquelle les entreprises les adoptent est leur flexibilité, qui permet de répondre à l'ensemble de leurs besoins. Les départements IT apprécient de pouvoir adopter des technologies « open source » en suivant leur propre rythme, en les intégrant facilement dans leurs environnements critiques. Ils peuvent personnaliser le logiciel et choisir un modèle tarifaire beaucoup plus souple que celui imposé par les acteurs propriétaires.
Pour toutes ces raisons, les discussions autour des logiciels « open source » d'entreprise sont aujourd'hui centrées sur leur potentiel, avec des projections optimistes sur les cinq prochaines années. De telles prévisions négligent la réalité : l'« open source » est déjà bien établi dans l'entreprise. Selon une récente étude du Gartner, plus de la moitié des entreprises interrogées ont adopté des solutions « open source » dans leur système d'information.
L'« open source » est l'un des développements culturels et informatiques les plus significatifs depuis vingt ans, et a démontré que des individus collaborant via Internet peuvent créer des produits rivalisant et dépassant même parfois ceux des plus grands éditeurs. Il a également montré dans quelle mesure des entreprises peuvent devenir plus innovantes et plus agiles tout en maîtrisant mieux leurs coûts, grâce à la communauté. Ce modèle continue de prendre de l'importance, favorisant l'intégration des environnements d'entreprise, des smartphones et même..., oui, de la voiture garée devant chez vous.
Bertrand Diard est cofondateur et PDG de Talend.

http://www.lesechos.fr/opinions/points_vue/0201919927625-l-open-source-une-revolution-295331.php?xtor=EPR-1500-[idees_debats]-20120228-[s=461370_n=9_c=907_]-409905656@1

L’impact des évolutions technologiques sur les équipes informatiques Par Pascal Danet, ingénieur système, Brocade

lundi 27 février 2012
Selon une récente étude de Gartner[1], malgré une augmentation prévue moins importante qu’en 2011, les analystes tablent pour 2012 sur une croissance de +3.7% des investissements dans le domaine de l’informatique. Cela se traduira par un volume d’investissements total de 3.800 milliards de dollars (contre 3.700 milliards en 2010). Les technologies, telles que le Cloud, la virtualisation ou encore la convergence des réseaux, marquent cette dernière décennie et vont impacter à moyen terme les équipes IT. Dans le cadre de ces investissements technologiques, la convergence des réseaux entraînera un changement de la conception des data centers.

Les entreprises se posent inévitablement la question des capacités de stockage et de la performance des réseaux. Pour être efficace et afin d’éviter la gestion coûteuse de multiples niveaux d’agrégation et réseaux distincts, elles doivent pouvoir simplifier leurs architectures vers des réseaux de type « fabric ». Il devient alors possible de miser sur la convergence du SAN (stockage) et LAN (réseaux), et dans ce cadre les équipes informatiques des entreprises vont également devoir se rapprocher.

L’hétérogénéité des équipes et des formations : un frein à la convergence

Les formations au stockage et réseaux SAN sont généralement assurées par les constructeurs, éditeurs, ou groupes professionnels tels que le SNIA, mais restent rares dans les cursus universitaires ou écoles d’ingénieurs. Cette faible présence dans les  cursus dits « classiques » s’explique par la spécificité du marché stockage, avec des réseaux SAN de quelques milliers de ports gérés par de petites équipes très qualifiées. Les constructeurs forment leurs ingénieurs avant-ventes, services et support aux protocoles stockage, et aux méthodes de travail très rigoureuses dues aux exigences de production des systèmes critiques, ou la stabilité et non perte des données dans les réseaux de stockage sont vitaux pour l’entreprise  cliente.
Il existe une multitude de formations banalisées sur les réseaux IP/Ethernet. Elles sont largement reconnues mais présentent des inconvénients majeurs pour le monde de l’entreprise : contenu très technique orienté produits et architecture, manque de neutralité car très influencées par les technologies, protocoles et règles d’architectures du constructeur dominant. Elles prennent peu en compte les contraintes de production auxquelles font face les entreprises, et sont plus influencées par les tendances technologiques du moment que centrées sur la simplicité et la continuité d’exploitation de solutions simples.

Cette divergence se retrouve dans l’entreprise et son organisation de production, avec des équipes opérationnelles LAN et SAN avec un ADN et des philosophies de travail très différentes, qui jusqu’à récemment n’étaient pas amenées à se rencontrer. Pour les uns réseau étendu à trois, voire quatre niveaux, multitude d’applications et de protocoles, notion de meilleur service avec acceptation tacite de sous dimensionnement et perte éventuelle de données. Pour les autres réseaux plats de type « fabric » haute performance, dédiés uniquement au stockage, avec tolérance zéro pour la latence ou pertes de données.
                                                                                       
Ces équipes réseaux ainsi que celles des serveurs et applications sont souvent gérées par la même direction. La convergence des réseaux et la virtualisation des serveurs vont entraîner inévitablement une convergence d’équipes multidisciplinaires avec un management mieux intégré permettant le partage des meilleures pratiques et d’outils de gestion communs.

Management et Best practices : point essentiel de la convergence des équipes

Dans un objectif d’une convergence des équipes, les constructeurs et intégrateurs peuvent  proposer des pistes de travail à leurs entreprises clientes.Ils doivent gérer en amont de la mise sur le marché des produits la convergence des équipes avant-ventes, services et support, composées historiquement d’ingénieurs certifiés dans des « silos » bien précis.

Le point de départ essentiel de cette convergence tient dans le rôle du management qui amène chaque équipe à connaître l’autre, s’appréhender et collaborer. Sans être imposé, ce changement permettra de créer une base commune de vocabulaire et meilleures pratiques  pour chaque projet. En effet, la convergence ne repose pas uniquement sur une solution technologique, elle est aussi dans les esprits et méthodes de travail. Il faudra également recentrer la mission de chaque ingénieur sur son métier et les impératifs de production de l’entreprise, plutôt que sur ses passions technologiques et la surenchère entre équipes. Chez un constructeur ou intégrateur les ingénieurs avant-vente, service et support portent les mêmes objectifs, subissent les mêmes contraintes et utilisent des méthodes de travail similaires, quelle que soit leur spécialisation technologique.

Dans la mise en place de cette convergence des équipes, l’une des premières étapes va être  d’organiser des entretiens croisés sur la manière donc chacun aborde sa mission, sa technologie, mais aussi son contact client et ses méthodes de travail.  Ces échanges permettent de mieux comprendre les métiers de chacun et de créer un vocabulaire commun. Le partage de connaissances se fera alors plus facilement lors d’acquisitions de nouvelles compétences techniques ou métier.

Certains ingénieurs resteront réfractaires au changement et choisiront de rester des spécialistes de leur secteur, d’autre feront un pas du réseau au stockage ou vice versa pour enrichir leur expérience  et se valoriser sur le marché. L’idéal n’est pas convertir chaque ingénieur mais de réunir les profils plus généralistes (tournés vers la simplicité, l’exploitabilité, le retour sur investissement, la continuité d’exploitation) avec les spécialistes de sujets technologiques pointus.

Cette équipe multidisciplinaire produira les outils, méthodes et meilleures pratiques communes nécessaires à la convergence : études des besoins, définition d‘architecture, pilotage de déploiement, tests, mécanismes de reprise sur incidents, procédures d’exploitation, etc …

L’ingénieur polyvalent « Stockage & Réseau » n’existe pas réellement pour l’instant et il doit donc être développé au sein des équipes informatiques de l’entreprise. Pour cela, il est essentiel que les équipes s’appréhendent, et travaillent ensemble à l’élaboration de méthodes communes  sous l’impulsion du management.



[1]
http://dsi.silicon.fr/sur-le-terrain/depenses-it-pour-2012-le-gartner-plus-prudent-1955
 
http://www.infodsi.com/articles/129522/impact-evolutions-technologiques-equipes-informatiques-pascal-danet-ingenieur-systeme-brocade.html?key=

Les 10 étapes clés pour réussir son projet de filtrage Par Alexandre Souillé, Président d’Olfeo

lundi 27 février 2012
L’utilisation d’Internet au bureau, met les entreprises face à cinq enjeux majeurs à maitriser pour un bon fonctionnement du système d’information :
- les enjeux juridiques : le non respect d’une obligation légale de la part d’une entreprise ou d’un usage illicite d’un salarié sur Internet depuis son poste de travail engage systématiquement la responsabilité du dirigeant et de l'entreprise.
- les enjeux liés à la baisse de productivité : Au bureau en 2010, 94 minutes par jour étaient consacrées au surf sur Internet, dont 63 % à des fins personnelles (soit 59 minutes par jour)*
- les enjeux liés à la sécurité du système d’information : le web 2.0, les sites de paiement en ligne, d’actualités, de téléchargement de fichiers … sont autant d’opportunités pour les pirates de pénétrer le réseau et se propager au sein de toute l’entreprise et ainsi endommager le système d’information ou récupérer des données sensibles.
- les enjeux liés à la performance du réseau : aujourd’hui, on regarde la télévision et on écoute la radio en streaming, on publie des vidéos personnelles sur son réseau social favori, … Ces usages demandent des besoins en bande passante considérables et se font bien souvent au détriment des applications professionnelles.
- les enjeux liés à la fuite d’informations : outre le risque d’intrusion par des logiciels malveillants, l’utilisateur peut être, volontairement ou involontairement la source de fuites d’informations. La généralisation de l'utilisation des plateformes Web 2.0 y participe très largement.

Pour maîtriser ces enjeux, il ne subsiste plus de doutes concernant le besoin et l’obligation de filtrer. Mettre en place une solution de filtrage, n’est pas une décision anodine car c’est à la fois protéger l’entreprise et respecter le droit du travail, le droit à la liberté résiduelles des salariés, ... Cette mise en oeuvre doit donc respecter un certain nombre d’étapes afin que celle-ci soit efficace.

1. Auditer le trafic Internet de l’entreprise
afin d’identifier clairement et précisément les risques pour l’entreprise et le système d’information face à l’utilisation d’Internet. Existe--?il un risque juridique pour l’entreprise : téléchargements illicites, jeux d’argent en ligne n’ayant pas l’accord de l’ARJEL ? La remise en cause de la sécurité du système d’information est--?elle due à de la fuite d’informations possible sur les réseaux sociaux ? La baisse de la productivité est--?elle due à une utilisation à titre personnel d’Internet de façon abusive ? A quel(s) moment(s) de la journée ?...

La baisse de performance du réseau est-elle liée à la consultation de sites professionnels ou non professionnels comme les radios en ligne ou encore la consultation de vidéos sur les plateformes dédiées ou de chaînes de télévision ? ... Les risques sont différents d’une entreprise à l’autre et d’un pays à un autre. Appliquer des règles générales à tous est un non sens. L’outil déployé pour réaliser cet audit doit permettre de détecter les risques réels de l’entreprise au regard de la législation en vigueur et la culture du pays.

2. Remonter les informations obtenues à la direction.
Après cette phase d’audit, il appartient au DSI de mettre en évidence les risques et les problématiques majeurs auxquels l’entreprise est confrontée auprès de sa direction générale. Il doit également apporter des solutions afin de répondre à ces risques. En l’absence de cette étape, le DSI peut voir sa responsabilité engagée pour négligence fautive en cas de litige.

3. Choisir la solution.
Le choix de la solution doit se faire sur des critères juridiques, culturels et techniques. Une solution de filtrage pertinente doit inclure un choix de catégories correspondant au droit pénal (exclure les sites et protocoles illicites). Elle doit également permettre un filtrage non discriminatoire dans le traitement des données à caractère personnel et collecter les logs nominatifs en cas de réquisition judiciaire. La solution doit offrir un taux de reconnaissance élevé sur des sites visités par les salariés et une excellente qualité de classement (que les sites soient répertoriés dans les bonnes catégories au regard de la législation et la culture du pays). Le choix d’une solution en amont permet de structurer les démarches suivantes.

4. Impliquer la direction de l’entreprise et la direction des Ressources Humaines
afin de définir les conditions d’utilisation d’Internet, tout en prenant en compte les besoins de chaque métier dans l’entreprise. Ainsi, la direction de la communication peut avoir davantage besoin d’utiliser Linkedin ou Twitter, tout comme d’autres départements dans l’entreprise peuvent avoir besoin de se rendre sur des sites spécifiques à leur métier. Il peut par exemple se révéler utile de demander à chaque chef de service de fournir une liste spécifique avec les catégories de sites à autoriser, à bloquer sur certaines plages horaires ou encore des sites soumis à des quotas en temps. Cette étape permet à la fois de définir les politiques de filtrage selon les groupes ou les utilisateurs et de commencer la rédaction de la charte ou d’un document d’information lié à l’utilisation d’Internet dans l’entreprise.

5. Rédiger les conditions d’utilisation du SI ou plus spécifiquement d’Internet.
Une charte s’inscrit dans une démarche d’explication et de sensibilisation quant aux enjeux et aux risques. L’objectif est de faire adhérer les collaborateurs et de définir une politique cohérente entre réalité technique et politique RH afin de maîtriser l’ensemble des risques. C’est d’ailleurs la réelle raison d’être d’une charte.

6. Déclarer l’outil de filtrage à la CNIL.
En France, la loi Informatique et libertés, vise ce que l’on nomme les données à caractère personnel et les traitements de données à caractère personnel. Les données des outils de filtrage peuvent être collectées, saisies, enregistrées, consultées, éditées. Elles font donc l’objet d’un traitement. Par conséquent, un dispositif de filtrage constitue un traitement soumis à la législation relative à la protection des données à caractère personnel. A partir du moment où l’outil retenu va collecter des données nominatives, il est nécessaire de déclarer la solution à la CNIL. Cette déclaration doit notamment préciser :
- la finalité du traitement,
- les données à caractère personnel traitées,
- la ou les catégories de personnes concernées,
 - la durée de conservation des données et l’indication de la date à laquelle les instances représentatives du personnel ont été consultées sur la mise en place des outils de filtrage. L’outil de filtrage peut être déployé dès la réception du récépissé de la CNIL.

Dans trois cas seulement, la DSI n’est pas obligée de faire cette déclaration :
-les employés de l’entreprise sont rendus anonymes
-l’entreprise dispose d’un Correspondant Informatique et Libertés (CIL)
 -le dispositif de filtrage ne permet pas un contrôle individuel du salarié

7. Consulter les institutions représentatives du personnel.
Lors de l’introduction d’une nouvelle technologie, les institutions représentatives du personnel doivent être consultées. L’introduction d’une technologie de filtrage est soumise à l’avis du comité d’entreprise ou du comité technique pour les administrations. Il en va de même pour la charte informatique. C’est avant tout une démarche de sensibilisation et les discussions doivent jouer un rôle pédagogique. Il convient de préciser qu’un avis négatif du comité d’entreprise ou du comité technique ne lie pas l’employeur, et ne l’empêche pas de mettre en place une nouvelle technologie au sein de son entreprise ou de son administration. En revanche, le défaut de consultation du comité d’entreprise correspond à un délit d’entrave sanctionné à ce titre par le Code du travail. Cette étape est d’autant plus indispensable qu’elle permet de faciliter l’acceptation de la solution et des conditions d’utilisation d’Internet par le plus grand nombre.

8. Informer les salariés.
Dès lors que l’entreprise collecte des données à caractère personnel, les salariés doivent être informés individuellement et collectivement. L’implémentation collective de la charte informatique passe par son affichage au sein de l’entreprise. Quant à l’information individuelle, il est important de s’assurer que chaque salarié ait bien pris connaissance individuellement des règles d’utilisation du SI en cas de litige. Lors de l’arrivée d’un nouveau collaborateur, la charte peut bien entendu être jointe au contrat de travail. La question est plus compliquée lorsqu’il s’agit de la mise à jour d’une charte existante.

Certaines solutions proposent un outil permettant de diffuser individuellement la charte soit à la première connexion Internet d’un salarié soit lors de la mise en vigueur d’une nouvelle version de la charte. Cet outil permet également de conserver les logs des employés ayant validé la prise de connaissance de la charte à une date précise. Il faut également savoir que la charte informatique n’est opposable aux salariés que si les étapes précédentes ont été respectées et si celle-ci a été déposée au greffe des prud’hommes et à l’inspection du travail en 2 exemplaires.

9. Respecter les dispositions réglementaires.
Une fois l’implémentation juridique de la mise en oeuvre de l’outil de filtrage traitée (droit du travail et droit informatique et libertés en particulier), il est indispensable d’assurer un maintien en conditions opérationnelles de la solution de filtrage et de sa conformité au droit. Il s’agit en particulier de s’assurer de la conformité légale du paramétrage tant au niveau des listes d’exclusions, qui pourraient être considérées comme discriminatoires, que dans le traitement des salariés qui doit être égalitaire. Il est également important de respecter les procédures permettant d’assurer l’utilisation précontentieuse ou contentieuse des éléments issus de l’outil de filtrage.

10. Conserver les logs et suivre les statistiques des employés
La dernière étape permet d’être en conformité avec la législation puisqu’il s’agit ici de conserver 365 jours de logs conformément au code des postes de communication modifié par la loi n=°2006-64 du 23 janvier 2006 relative à la lutte contre le terrorisme. Enfin, il reste essentiel de suivre les statistiques de navigation des salariés afin de prévenir tous risques liés à de nouvelles habitudes de surf. 

http://www.infodsi.com/articles/129523/10-etapes-cles-reussir-son-projet-filtrage-alexandre-souille-president-olfeo.html?key=

La Tragédie des facteurs communs

lundi 27 février 2012
X.509 (#) est un standard de l'ITU Telecommunication Standardization Sector pour les infrastructures à clés publiques. (Il est également parfois employé dans les infrastructure de gestion de privilèges pour le traitement des autorisations.) Dans cette norme, un certificat garantit l'association d'une clé publique à une entité nommée et identifiée. Les certificats sont délivrés par des autorités de certification qui peuvent dépendre les unes des autres dans une forme hiérarchique. Les navigateurs du marché sont livrés, par exemple, avec un certain nombre de certificats des autorités « racines » pré-installés de façon à ce que les certificats SSL des éditeurs et des fournisseurs de services soient immédiatement reconnus.


OpenPGP(#) est un autre dispositif populaire sur Internet pour chiffrer les échanges et authentifier les messages. Il fonctionne sans hiérarchie d'autorités de certifications, comme celles du standard X.509, et met également en oeuvre un chiffrement symétrique à clés publiques.

Les clés publiques sont donc devenues avec la généralisation des infrastructures de sécurité — que l'on pense aux protocoles SSL/TLS (#) et HTTPS (#), par exemple — l'épine dorsale du e-commerce, du paiement des transactions en ligne, de l'authentification des utilisateurs de services Web mais également de toutes les télécommunications, via leur rôle dans les routeurs, les équipements de télécommunications, les cartes à puces et les lecteurs, et dans la prolifération envahissante des devices connectés qui nous submerge.

Une cladistique des clés publiques. À première vue, ces clés publiques sont d'apparence bien modeste au regard de l'importance qu'elles ont prise aujourd'hui dans tous les secteurs de l'économie numérique : ce ne sont, après tout, que des nombres entiers, si connus et ressasses qu'on les dit « naturels ». Mais, pas de méprise ! Ces entiers ne sont point les chétives créatures qu'ils paraissent à l'oeil non averti...

Le naturaliste arithméticien porté sur la cryptographie distingue ainsi dans la zoologie des clés publiques quelques clades particulièrement intéressants. Les modules RSA, peut-être les plus populaires et les plus connus — nommés d'après Ron Rivest, Adi Shamir et Leonard Adleman en 1978 (#) — sont des nombres entiers qui sont le produit de deux très grands nombres premiers : n = pq, où p et q représentent ces très grands nombres premiers. La robustesse de RSA repose sur la difficulté que représente la factorisation de n : c'est-à-dire l'effort de calcul nécessaire pour déterminer p et q connaissant n. C'est un problème pour lequel on ne connaît pas à ce jour d'algorithme en temps polynomial. Dans l'infrastructure à clés publiques RSA, le message M est chiffré en calculant Me [n], M porté à la puissance e, modulo n, la clé publique du destinataire. (On suppose que tous les messages sont au final codés comme des entiers, ou des blocs d'entiers.) Le destinataire, seul à connaître les fameux très grands nombres premiers p et q du module RSA, est donc seul à posséder la clé privée d qui lui permet de déchiffrer le message crypté Me. En effet, connaissant p et q, d et e ont été choisis tels que ed - 1 soit divisible par (p - 1)(q - 1) ; du coup, pour déchiffrer on élève à nouveau le message crypté à la puissance d modulo n et l'on obtient Med qui n'est autre que M lui-même modulo n. (Cette dernière identification miraculeuse est due au Petit théorème de Fermat (#), l'autre gus de Montauban, notre arithméticien national plus fameux par son grand théorème, dit aussi le dernier, démontré il y a quelques années (#) par Andrew Wiles.)

Dans cette cladistique des clés publiques on trouve également les clés El Gamal (#) qui en appellent à l'imposante théorie algébrique des nombres. Cette fois la clé est constituée de trois entiers : p un nombre premier, g un générateur du groupe des entiers modulo p, et y un entier (public) tel que y = gxx, un entier strictement inférieur à p - 1, est la clé privée.

D'autres clés publiques sont utilisées pour la signature numérique ou DSA (Digital Signature Algorithm) défini dans les standards du FIPS (FIPS 186-3) promulgués par le gouvernement américain. La clé publique DSA est un quadruplet (p, q, g, y) dans lequel p et q sont des nombres premiers tels que q divise p - 1, g est un générateur d'un sous-groupe d'ordre q du groupe des entiers positifs modulo p et, comme dans le El Gamal, y = gxx, un entier strictement inférieur à q, est la clé privée.

Enfin on trouve également les clé publiques basées sur les courbes elliptiques (#) depuis les premiers travaux de Miller en 1985, dont je vous ferai grâce des détails puisque, vaillant lecteur, vous êtes malgré tout parvenu jusqu'ici !

De la poliorcétique des clés publiques. Inutile de dire que ces clés publiques ont été, depuis la publication des premiers algorithmes de chiffrement, l'objet d'attaques innombrables et furieuses tant des mathématiciens intéressés à la démonstration de leur robustesse que des hackers sublimés par l'exploit et la gloire du cassage des infrastructures de sécurité. Dans l'ensemble, cependant, le secret RSA — pour prendre le plus répandu — est plutôt bien gardé (#) et les ingénieux algorithmes de décomposition en facteurs premiers lancés à son assaut n'ont pas encore fait tomber la forteresse.

Il est difficile de résister ici à la tentation de mentionner quelques uns de ces algorithmes qui sont de véritables petits bijoux calculatoires (#). Par exemple, le crible algébrique (GNFS General Number Field Sieve) est un algorithme, fondé sur l'arithmétique modulaire particulièrement efficace pour la décomposition en facteurs premiers. L'algorithme de décomposition par fractions continues (#) plus ancien est toujours efficace, mais on lui préfère le crible quadratique de Pomerance (#) qui en 1990 établit un record en décomposant un nombre de 116 chiffres — en 1994, il décomposait un module RSA de 129 chiffres, premier d'une longue série de réussites des hussards de l'agèbre modulaire à l'assaut de la forteresse RSA : le dernier en date, en 2009, étant la décomposition d'un module RSA long de 768 bits (#) rendant aujourd'hui préférable le choix de clé de 1 024, voire 2 048 bits, dans les infrastructures PKI. Les algorithmes de Pollard (#) et de Williams, dont dérive le GNFS, établirent les records ultérieurs et furent employés dans les premières recherches de facteurs premiers réparties sur un très grand nombre de machines — technique de parallélisation maintenant très souvent employée pour l'analyse de très grands volumes de données en météorologie, en génétique, en astronomie, souvent via de simples économiseurs d'écrans proposés en libre chargement. Son titre de gloire fut la factorisation en 1993 (#) du neuvième nombre de Fermat — encore lui ! — 2512 + 1. Citons encore l'imprononçable SQUFOF (Square Form Factorization) de Daniel Shanks (#), et la factorisation par utilisation de courbes elliptiques (#) de Lenstra dans cette revue superficielle de l'attirail guerrier du cryptographe.

Si les modules RSA résistent encore c'est que sous leur frêle constitution de simple produit d'entiers, leur robustesse réside dans un choix des facteurs premiers p et q bien loin d'être innocent. La génération des clés pour les algorithmes comme RSA et ceux mentionnés précédemment est méticuleusement spécifiée dans plusieurs standards comme PKCS, IEEE 1363-2000, FIPS 186-3, ANSI X9.44 et ISO/IEC 18033-2, pour précisément résister aux attaques connues et anticipées. Cependant, première ombre au tableau réel qui s'annonce moins idyllique que le satisfecit irénique qui, semble-t-il, prévaut aujourd'hui, à l'examen approfondi (#) ces standards bien intentionnés diffèrent substantiellement les uns des autres. Cette diversité semblerait indiquer qu'il existe un consensus autour de l'idée que la robustesse d'un module RSA ne dépendrait pas nécessairement de l'exactitude de l'algorithme de génération. Et, de fait, on peut imaginer plusieurs processus de construction des modules RSA : construction théorique (#) — où p < q < rp pour r > 1 — ; construction simple décrite dans les standards et dans certaines implémentations comme OpenSSL, GnuPG et la librairie crypto de GNU, dans laquelle p et q sont choisis dans des intervalles donnés ; construction algorithmique dans laquelle, une fois choisi p, un calcul détermine q, pour que le produit tombe dans un intervalle choisi à l'avance. L'analyse de ces constructions démontre en effet que si la factorisation est dure (en temps non polynomial) celle des modules RSA uniformément construits par ces processus l'est également, ce qui serait donc plutôt positif. L'analyse des implémentations existantes, en revanche, montre qu'aucune d'entre elles (GNU crypto, GnuPG, OpenSSL, Openswan) ne suit exactement les standards en question (PKCS, IEEE 1363-2000, FIPS 186-3, RSA-OAEP, IEEE 1363-2000, NESSIE), avec pour résultat net que certaines implémentations et certains standards engendrent ces modules RSA de façon non uniforme. La non-uniformité, rappelons-le, ne met pas a priori en danger la sécurité des modules RSA, i.e la difficulté de leur factorisation qui est leur utime rempart, mais peut avoir un impact plus subtil qui vient d'être brutalement démontré par deux études de la population des clés publiques in vivo.

L'ethnologie des clés publiques. Sur ces considérations, somme toute relativement rassurantes, deux papiers récemment publiés — l'un à la conférence IMC 2011 (#), en novembre dernier à Berlin, par une équipe de TU München (#) ; l'autre dans l'ePrint Archive, mi-février 2012, par une équipe de l'EPFL (#) — distillent un troublant sentiment de panique. Ces ethnologues numériques ramènent des nouvelles bien inquiétantes de leurs études in vivo des clés publiques et des certificats X.509 tels qu'ils sont aujourd'hui utilisés dans leur habitat naturel Internet.

Tels des Dian Fossey de l'arithmétique, l'équipe de la TU München a vécu plus de 18 mois en compagnie de certificats X.509 sauvages, dans leur milieu Internet naturel, collectant des données depuis le premier million de sites Web les plus populaires dans le classement d'Alexa (#) et écoutant plus de 250 millions de sessions SSL/TLS sur le réseau universitaire allemand servant 120.000 personnes. Les résultats sont édifiants : l'infrastructure de certification X.509 actuellement en ligne se trouve dans un état avancé de détérioration.

Le pourcentage de certificats qui ne déclencheraient pas d'avertissement à l'utilisateur chez un client utilisant le référentiel racine de Mozilla (#) — qui a pourtant du pas mal grossir ces dernières années — ne dépasse par un très faible niveau de 18 %. Ce faible niveau de conformité s'explique par le très grand nombre de chaînes de validation incorrectes (40 % de tous les certificats vus !) et l'encore plus grand nombre de noms d'hôte incorrects ou manquants dans le certificat — ce qui contredit l'utilité et l'existence même d'un certificat en premier lieu ! Autres problèmes récurrents, les dates de validité des certificats depuis longtemps expirées, les certificats « escrocs » sans autorité racine, et le très grand nombre de certificats partagés par des entités sans relation entre elles (menant au problème d'usurpation d'identité, par exemple). Bref, un constat de déliquescence bien loin de la netteté chirurgicale du dispositif in vitro des spécifications des organismes de standardisation.

Mais ce n'est pas tout ! La seconde étude ethnologique de l'EPFL qui, quant à elle, a collecté plus de 11 millions de clés publiques par des scans d'un grand nombre d'hôtes Internet et en analysant le nouvel Observatoire du SSL (#) récemment mis en ligne par l'Electronic Frontier Foundation bat en brèche la belle assurance des arithméticiens modulaires.

Les 11,7 millions de clés publiques vues contiennent 6,4 millions de modules RSA distincts ; le reste est réparti entre clés El Gamal et clés DSA — une seule clé ECDSA repérée, un hapax. On y lit encore les scories de la dévastation due à la vulnérabilité de l'OpenSSL Debian de 2009 (#). Notée en mai 2008, une erreur de jugement avait conduit à retirer une seule ligne de code du générateur de nombre pseudo-aléatoire du paquetage OpenSSL dans la distribution Debian. Cette suppression entraînait une insuffisance d'entropie dans l'initialisation du générateur — à chaque usage — dont les nombres aléatoires ne devenaient plus aussi imprévisibles que théoriquement prévu, et qui, en conséquence, compromettait toutes les clés publiques engendrées sur les distributions dérivées de Debian, entre septembre 2006 et mai 2008. Par ricochet tous les systèmes, même non Debian, qui auraient utilisés des clés engendrées par l'OpenSSL Debian courraient de ce fait le risque d'être infectés et d'avoir été compromis. Épidémie majeure de compromission potentielle des transmissions et des échanges d'autant plus dangereuse qu'elle est largement sourde et invisible du grand public ! Ces clés furent blacklistées (#) et ces listes diffusées dans toutes les installations avec les mises à jour. Mais ces clés faibles circulent toujours aujourd'hui, leur proportion (0,3 %) est en baisse depuis 2009.

Ces modules RSA uniques, une fois collectés, ont été soumis à des analyses de factorisation, superficielles au vu de leur nombre, mais significatives quant aux conséquences réelles de leur usage sur le Net. Elles visent, notamment à vérifier l'hypothèse sous-jacente à la sécurité des architectures PKI qui est que dans la génération de clés publiques les choix antérieurs de nombres premiers ne sont jamais répétés. Et là, patatras ! Tout le bel édifice s'écroule devant les faits : sur 6,6 millions de certificats X.509 et clés PGP contenant des modules RSA, 270.000, soit 4 % partagent le même module RSA bien que n'impliquant des entités totalement étrangères. La duplication des clés est parfois la règle plutôt que l'exception...

Par ailleurs, l'étude a trouvé 12.934 modules RSA, soit 2 pour 1000, n'offrant aucune sécurité. Même en se restreignant aux modules RSA de taille 1.024 bits, les modules RSA en liberté aujourd'hui n'assurent au mieux qu'un niveau de sécurité de 99,8 %. (Une illustration saisissante : 98,49 % des certificats X.509 utilisent le même exposant RSA, 65.537, le lointain second à 0,76 % étant 17.) Lorsqu'on regroupe les 6.185.228 certificats X.509 lorsqu'ils partagent le même module RSA — les groupes qui ne contiennent qu'un seul module sont les « bons », leur sécurité est garantie par la solidité théorique de RSA — on trouve avec désespoir plus de 14 groupes de plus de 1.000 certificats ayant des modules RSA communs. Au total, l'étude ne dégage que 5.989.523 modules RSA distincts qui, de surcroît, malgré les factorisations des modules de 512 bits en 2006 et de 768 bits en 2009, ont à 2,4 % des tailles encore inférieures à 768 bits. Aujourd'hui 73,9 % sont des modules RSA de 1.024 bits, 21,7 % de 2.048 bits et le reste est constitué d'entiers de tailles supérieures, jusqu'à 16.384 bits (pour 181 d'entre eux). Mais plus grave encore, une grande proportion des ces modules RSA ont en commun l'un de leurs deux nombres premiers (les p et q mentionnés plus haut) ce qui entraîne la perte totale de sécurité parce que leur décomposition commune est simplifiée par des algorithmes ad hoc (#).

L'aléatoire est au coeur des systèmes de chiffrement et faute de les tester correctement et de savoir tester correctement les générateurs de nombres aléatoires, on se rassurera à trop bon compte de leur fiabilité et de leur sécurité. Le ton alarmiste de certains commentaires publiés (#) sur cette étude est bien de mise : elle tire la sonnette d'alarme sur un problème profond et difficilement indétectable des architectures de sécurité. Quelques équipes innovantes travaillent aujourd'hui sur des nouvelles pistes pour y remédier. La jeune pousse MassiveRand — dont cet auteur est un très modeste actionnaire minoritaire — (#) par exemple, propose un TRNG True Random Number Generator, générateur de nombres aléatoires non déterministe) à très haut débit, pour les applications dans lesquelles la qualité des nombres aléatoires est cruciale.

Comme le répète inlassablement Bruce Schneier (#) les mauvais générateurs de nombres aléatoires nuisent gravement à la sécurité, quelle que soit l'ingéniosité du dispositif mis en oeuvre.

http://www.infodsi.com/tribune/129475/tragedie-facteurs-communs.html?key=

Enquête Pitney Bowes Software Le morcellement des canaux reste le principal défi de la relation client

lundi 27 février 2012
Courrier traditionnel, mail, télémarketing, messages SMS, réseaux sociaux, point de vente, centre d'appel, site Web... les canaux aujourd'hui pour toucher les clients sont multiples. Si la coordination de ces canaux pour toucher de manière homogène chaque client est un objectif bien compris par la très grande majorité d'entreprises, 3 sur 10 seulement déclare y parvenir. C'est ce qu'indique une enquête réalisée par Pitney Bowes Software.

La maîtrise du marketing multicanal constitue bien une priorité des grandes entreprises, mais de nombreux obstacles existent et les empêche. L'étude « Disconnected Customer Channels » montre que le défaut d’intégration et l'augmentation continue du nombre de canaux freinent la communication multicanale.



 


Les principaux résultats de cette étude qui s’est concentré sur les secteurs de la Finance, des Télécommunications et des services publics démontrent que :

- Il est difficile pour les entreprises d’intégrer les canaux de communication : 90 % d’entre elles souhaitent atteindre cet objectif, mais seulement 31 % y parviennent.

- Cette situation est aggravée par la multiplication du nombre de canaux : plus de la moitié (53 %) des entreprises approche leurs clients via les réseaux sociaux ; pourtant, seulement 8 % réussissent à mettre en œuvre des communications intégrées et multicanales en fonction des préférences des clients.

- Cela conduit souvent à une perte de clients. Les entreprises ayant participé à l’étude considèrent que 32 % des départs de clients pendant la période de fidélisation sont dues à la fragmentation des communications et 26 % au marketing de masse.

- 27 % des interviewés ne capitalisent pas sur le canal utilisé pour la prise de contact et 9 % seulement disposent de systèmes de modélisation du comportement client, permettant de s’adapter pour profiter au mieux des opportunités.

 

L’étude révèle par ailleurs que, si la plupart des entreprises tentent de créer de la cohérence et des liens entre leurs différentes communications marketing, ce qu’elles estiment être une bonne pratique métier, seule une minorité y parvient. Celles qui ont l’habitude d’utiliser des techniques de segmentation marketing sophistiquées, basées sur une connaissance approfondie de leurs clients, sont plus susceptibles de se tourner vers les outils d’analyse prédictive et de communiquer avec leurs clients via leurs canaux préférés. Cependant, l’étude montre que 2 % seulement des entreprises ont atteint un tel niveau.

Selon Gary Roberts, Executive Vice-President EMEA chez Pitney Bowes Software : « pour connecter les différents canaux en vue de renforcer la fidélité et la valeur à vie de leurs clients, les entreprises peuvent s’approprier les technologies de marketing cross canal, adapter l'utilisation des canaux à chaque opportunité, particulièrement pour gérer la fidélisation et la première prise de contact, et acquérir une meilleure connaissance de leurs clients au cours de chaque interaction pour mieux adapter les communications ».



Pour télécharger l'étude

_______________
L’étude commandée par Pitney Bowes Software a été menée par l’agence Opinion Matters. 250 responsables marketing et dirigeants d’entreprises proposant des services aux consommateurs dans les domaines de la finance, des télécommunications et des services publics, comptant plus de 1 000 employés et situées au Royaume-Uni, en France et en Allemagne, ont été interrogés.

lundi 27 février 2012

Big Data, le défi de l'information pléthorique

L'entreprise n'a plus seulement affaire à de l'information précise et fine, elle doit composer avec une masse inédite de données, issue de la multiplicité de canaux de communication et d'outils numériques. Une masse d'autant plus difficile à appréhender et traiter qu'elle agrège des donnés hétérogènes et non-structurées.
Données CRM

Le traitement de données n'est pas une problématique nouvelles pour les entreprises. Cependant, la culture du "datawarehouse" et du logiciel d'extraction de données ne suffira pas pour encaisser le choc d'un nouveau phénomène : la grande donnée, ou Big Data. A savoir l'afflux permanent et torrentiel d'informations dans des proportions inédites. Les raisons ? La multiplicité de canaux de communication et de collecte de données où le consommateur et utilisateur se fait directement producteur d'information sans même toujours savoir, d'ailleurs, qu'elle sera exploitée. Il y avait déjà les données de connexion et de navigation Internet, les informations sur les habitudes de consommation sur les sites marchands, sur les publicités vues ou cliquées, sur le temps de consultation. Les mobiles ont ajoutées les données de géolocalisation. Facebook, Twitter, les médias sociaux en général ont ouvert les vannes à une production libre, en temps réel et tous azimuts mais qui reste stratégique pour peu que l'on sache en extraire l'essentiel.
Un atout économique
Les outils logiciels se multiplient pour optimiser le stockage et l'étiquetage des données mais aussi analyser les contenus, en intégrant notamment l'analyse sémantique pour pouvoir traiter des verbatim de consommateurs sur les sites, les pages Facebook ou les fils Twitter des marques. La production par des salariés de commentaires sur Intranet, d'échanges entre collègues, de notes ou de posts informelles sur les réseaux de l'entreprise peuvent s'avérer précieux pour identifier des compétences et des savoirs. Big Data est donc un nouveau défi adressé aux entreprises : un gisement de connaissances clients et de performances qui, bien analysé et traité, s'avérera un puissant atout économique. Mais qui imlique aussi de nouvelles organisation et un nouveau dimensionnement des infrastructures.

http://www.atelier.net/trends/files/big-data-defi-de-linformation-plethorique

Tribune : "Informatique décisionnelle – informatique transactionnelle : il est temps de réunir les deux mondes !"

Le 23 février 2012 (13:35) - par InnoverMaintenant.fr
 
Tout au long de l'année 2012, InnoverMaintenant.fr, blog édité en partenariat avec SAP France permettra à Nicolas Sekkaki, Directeur général de l'éditeur en France, de donner son point de vue sur la création de valeur par les systèmes d'information au service des entreprises. Ces tribunes seront régulièrement publiées sur LeMagIT. Cette semaine InnoverMaintenant.fr revient sur la réconciliation des mondes décisionnels et transactionnels grâce aux technologies In Memory.
Quand Hasso Plattner, le co-fondateur de SAP, a commencé à évoquer les travaux sur le In-Memory Computing menés au sein de l’institut de recherche qu’il finance, c’est le scepticisme qui a accueilli ses déclarations. Quand on y repense aujourd’hui, ce n’était que logique. Car la trajectoire que dessinait alors Hasso Plattner bousculait des certitudes ancrées dans les directions informatiques des entreprises depuis des années, à commencer par celle voulant que l’informatique décisionnelle, celle des rapports et autres tableaux de bord, soit forcément distincte du monde transactionnel, où l’entreprise enregistre ses transactions au fil de ses activités.
Cette séparation des deux univers se traduit par une complexité des sous-jacents techniques : ETL pour extraire les données, datawarehouse (ou entrepôt de données, NDLR) pour les stocker, datamarts, agrégats… L’industrie a rivalisé d’ingéniosité pour rendre le décisionnel suffisamment réactif aux besoins des entreprises. D’emblée, c’est tout cet édifice que Hasso Plattner a voulu remettre en cause. Dès 2009, dans un livre blanc fondateur au titre sans ambiguïté (« Une approche commune pour OLTP et OLAP en utilisant une base de données In-Memory en colonnes« ), il expliquait : « J’ai toujours pensé que l’arrivée des solutions de datawehouse n’était qu’un compromis. La flexibilité et la vitesse que nous avons gagnées l’ont été au prix d’un surcroît de gestion en extraction et chargement de données, ainsi que de contrôles accrus en matière de redondance ». L’objectif était donc tracé ; son caractère radical ne pouvait que susciter le scepticisme évoqué au début de mon billet.
Cet objectif est désormais à portée de main. La curiosité, l’intérêt ont supplanté l’incrédulité. Curiosité et intérêt des métiers, mais aussi de la DSI.

http://www.lemagit.fr/article/decisionnel-sgbd-in-memory-hana/10531/1/tribune-informatique-decisionnelle-informatique-transactionnelle-est-temps-reunir-les-deux-mondes/?utm_source=essentielIT&utm_medium=email&utm_content=new&utm_campaign=20120227&xtor=ES-6