Quelles leçons tirer du big data ?

Pour 60% des entreprises, le Big Data va bousculer leur marché…

C’est ce qui ressort d’une enquête de Capgemini Consulting, faite en novembre 2014 sur plus de 200 sociétés, à l’international.

Mais pourquoi parler de cela, me direz-vous, puisque le Big Data, comme le nom l’indique, concerne la gestion d’énormes stocks de données, en tout cas beaucoup plus que la plupart des lecteurs de ce blog ?

En fait, certaines conclusions me semble-t-il, nous concernent. Pour ma part, je vois plusieurs parallèles avec la situation que je rencontre chez des petites ou moyennes entreprises, ou des associations et collectivités territoriales…

1) Les mises en place jugées nécessaire

Les chiffres seraient sans doute un peu différents. Mais je rencontre beaucoup d’organismes en pleine interrogation sur la gestion de leurs données. Vieille base à refondre complétement, fichiers Excel dispersés partout, nécessité de s’ouvrir à la mobilité et au web, souci de mieux gérer au quotidien, améliorer le service aux clients…  les motifs ne manquent pas. Presque tous sont conscients que cette évolution est vraiment nécessaire, et qu’il faut y investir avant qu’il soit trop tard… La base de données conçue comme arme anti-concurrence pour lutter dans ces temps difficiles, c’est un discours un peu nouveau par rapport à il y a quelques années…

2) Des réussites et des échecs

Chaque pays a connaissance à certains moments des difficultés de tel ou tel organisme à réussir un gros projet informatique. Mais c’est la même chose pour des projets plus simples… Régulièrement nous sommes sollicités pour reprendre un projet non fini, que ce soit un projet développé en interne ou avec des prestataires externes. Il y a effectivement un certain pourcentage d’échecs, personne ne peut le nier. L’enquête en montre certaines raisons. Pour ma part, je vois souvent le fait de sous-estimer le projet, que l’on juge a priori très simple. Je ne compte plus le nombre de fois où quelqu’un nous contacte avec la formule : « mon besoin est très simple, vous devriez pouvoir y répondre rapidement » (sous entendu pour pas cher). Le pire est que souvent, c’est relativement simple, mais qu’à cause de cette simplicité ressentie, il y a un refus de l’étudier sérieusement. Or pour la maison de vos données, ce sont aussi les fondations qui font la solidité…

3) Secret de la réussite : en centraliser la gestion

C’est la conclusion de l’enquête. C’est également ce que me disent mes 27 ans d’expérience. Malheureusement, trop souvent, un organisme appelle un prestataire, et sous prétexte que c’est lui le professionnel, ne se préoccupe pas vraiment de ce qui se passe en interne, au sein des équipes du dit organisme.

Et c’est même encore pire si le développeur est interne, car sous prétexte qu’il connait la maison, il va pouvoir se débrouiller tout seul. C’est pour moi une des principales causes d’échec ou de retard… Je le vois en ayant suivi depuis des années ceux que j’appelle les « personnes-resources FileMaker ».  Trop isolées au sein de leur organisme, préoccupées des aspects purement technique de FileMaker (comment je fais ce foutu script…), bousculées par les utilisateurs (t’as pas encore fini ? Pourtant c’est simple ce que je demande…), elles oublient de réfléchir sur le fond et perdent de vue leur vraie mission.

Conclusion ?

Chacun aura la sienne, en fonction de sa situation.

Pour ma part, cela renforce ma conviction.
Pour réussir un projet FileMaker la formation technique est nécessaire mais non suffisante.

• Il faut réfléchir aux données que l’on veut gérer (lesquelles, pourquoi, quand, par qui, comment… ?).
• Il faut travailler en lien étroit avec les utilisateurs (même si on croit bien les connaître, en tant que collègue)…
• Pour cela, la méthode agile est préférable à la méthode classique
• Il faut penser globalement, et pas uniquement service par service, département par département…
• Même chose pour l’ensemble de l’informatique (FileMaker n’est pas isolé sur son île)…
• Il faut un coordinateur réel, que cela soit une personne ressource FileMaker (développeur interne), ou un chef de projet MOE (maitre d’œuvre) en cas de développeur externe. Et ils doivent se former en conséquence, ce que l’on néglige trop souvent…
• Le développeur ne doit pas être seul. Un développeur professionnel externe a un collègue comme vis à vis, voire travaille en duo. Une personne ressource interne doit avoir aussi un regard externe (coaching, groupe de pairs…).

Rassurez-vous, face à une telle liste, je reviendrai pour détailler certains de ces points…

Michel Lansard

Source pour l’enquête :
http://www.journaldunet.com/solutions/dsi/etude-capgemini-big-data.shtml

Tags: développement