Nieuwbourg Group : La gestion de projet semble chercher le concept porteur. Pourquoi ce secteur manque-t-il à ce point de reconnaissance ?
Thierry Dupiot, directeur général de Makhila
Thierry Dupiot : Je crois que cela repose sur plusieurs critères. Le premier est qu’effectivement la gestion de projet n’est pas sexy et à plusieurs titres. Elle n’apparaît pas obligatoirement stratégique aux yeux des entreprises. Le plus souvent, elles ne la perçoivent pas comme un levier qui leur fera gagner des parts de marché ou augmenter leur visibilité. La gestion de projet est perçue comme un moyen d’économiser de l’argent plus que d’en gagner. Et les leviers d’économie sont rarement attrayants. Ils peuvent même avoir une image négative ou péjorative, souvenez-vous des grèves qui ont accueilli la mise en place de certains ERP. Les associations d’idées desservent également la gestion de projet, c’est notamment le cas avec le bug de l’an 2000.
Ensuite, les cabinets d’analyse ont catalogué la gestion de projet parmi les outils de gestion, au même titre que la comptabilité, la production, etc. ce qui pénalise encore l’image de ce domaine applicatif. Enfin, il faut reconnaître que ces solutions restent assez difficiles à appréhender, dans le sens où il s’agit de travailler beaucoup plus sur la relation humaine que sur la solution elle-même ou sur un produit. Il faut comprendre que ces applications ne sont que des vecteurs, des points d’appuie et non des outils qui se justifient par eux-mêmes.
Ensuite, les cabinets d’analyse ont catalogué la gestion de projet parmi les outils de gestion, au même titre que la comptabilité, la production, etc. ce qui pénalise encore l’image de ce domaine applicatif. Enfin, il faut reconnaître que ces solutions restent assez difficiles à appréhender, dans le sens où il s’agit de travailler beaucoup plus sur la relation humaine que sur la solution elle-même ou sur un produit. Il faut comprendre que ces applications ne sont que des vecteurs, des points d’appuie et non des outils qui se justifient par eux-mêmes.
NG : La gestion de projet est souvent perçue comme un moyen de contrôle, de contrainte… La mise en place de ce type d’outil n’est-elle pas d’autant écartée que le terrain est culturellement réfractaire ?
TD : Cela joue certainement, mais un autre paramètre intervient. Beaucoup de chef de projets - donc à priori les premiers concernés - ne sont pas de véritables chefs de projet, au sens où dans la plupart des cas ils sont incapables de gérer un projet avec un papier et un crayon. Ils savent dessiner le projet initial, des études d’ingénieur le leur ont enseigné. Mais la gestion de projet ne se limite pas à dessiner un projet idéal et à regarder la manière dont il vit. Il s’agit de tracer un cercle vertueux : à partir du dessin initial, il faut modéliser donc construire un projet, travailler sur des scénarii - que se passe-t-il si tel ou tel autre évènement se produit -, agir en choisissant l’un des scénarii, le mettre en œuvre et constater ce qu’il se passe, quels sont les écarts éventuels par rapport au scénario choisi, reboucler, analyser la conséquence de cet écart sur le planning initial, repartir dans une élaboration de scénarii, agir et procéder au reporting. Or très peu de chefs de projets savent gérer cela simplement avec un papier et un crayon. Partant de là, l’intervention d’un outil ne change pas grand chose.
NG : Comme d’autres domaines, la gestion de projet souffre de la confusion qui veut que l’informatisation résolve tous les problèmes, même s’il s’agit de compétence ?
TD : A cela s’ajoute un effet pervers. Généralement et à fortiori en France, les chefs de projets sont nommés comme une simple évolution de carrière, alors qu’il s’agit d’un poste très technique. Le portrait est certainement réducteur, mais il exprime une situation fréquemment rencontrée. Des personnes obtiennent se poste parce qu’elles le mérite au sens de leur ancienneté, de leur savoir-faire, de leur expérience et d’une somme de critères d’évolution. Il est heureusement normal de faire évoluer ses salariés, la question n’est pas là. Le problème est qu’elles parviennent à ce poste de chef de projets sans forcément acquérir les compétences et techniques nécessaires. Cette fonction induit de la prise de décision et donc un pouvoir adéquat. Il faut maîtriser son outil qui en l’occurrence est la gestion de projet et non uniquement les fonctions qui par reconnaissance ont motivé la promotion.
NG : La promotion à l’ancienneté sera dure à troquer contre une promotion au mérite basée sur une compétence ou un potentiel, accompagnée ou non d’une mise à niveau… Comment reconnaître un chef de projet ?
TD : Prenez n’importe quel sport, le capitaine de l’équipe n’est pas obligatoirement le meilleur joueur. C’est celui qui est capable de fédérer, de prendre des décisions, de dire que la direction est mauvaise et que l’entreprise va dans le mur… Lors de la coupe du monde de football 1998, Didier Deschamps était le capitaine de l’équipe de France. Or, il n’a jamais été considéré comme le meilleur joueur de l’histoire du football français. Mais alors quel leader, quelle capacité à galvaniser les joueurs ! Un chef de projet procède de la même logique, il n’est pas forcément un super technicien. Ensuite, il y a l’image et le manque d’attraits associés au poste. Dans ce contexte, une entreprise qui promeut un bon élément à un poste de gestion de projet est rarement motivée à investir dans une formation complémentaire. Les chefs de projets doivent être moteurs dans la mise en place de leurs solutions, notamment ceux qui interviennent au déploiement. Une acceptation forte du projet est nécessaire. Et généralement les prestataires préconisent toujours une mise à niveau des chefs de projet sur leur métier, avant de parler boutique.
L’interprétation comme une remise en cause des compétences et de la légitimité est un risque, que les cabinets de conseils savent élégamment contourner. Le marketing sait généralement bien expliquer en quoi cette démarche est essentielle, sans froisser ni créer de remise en question. Il s’agit d’établir le socle ou le référentiel commun d’entreprise… Généralement, derrière les outils de gestion de projet, nous parlons de méthodologie, de conduite de projet ce qui fait passer l’idée de comment apprendre le métier. Après, il y a toujours des irréductibles, mais comme partout et en tout chose.
L’interprétation comme une remise en cause des compétences et de la légitimité est un risque, que les cabinets de conseils savent élégamment contourner. Le marketing sait généralement bien expliquer en quoi cette démarche est essentielle, sans froisser ni créer de remise en question. Il s’agit d’établir le socle ou le référentiel commun d’entreprise… Généralement, derrière les outils de gestion de projet, nous parlons de méthodologie, de conduite de projet ce qui fait passer l’idée de comment apprendre le métier. Après, il y a toujours des irréductibles, mais comme partout et en tout chose.
NG : La multiplication des concepts et des acronymes - quête d’un terme fédérateur qui réhabiliterait l’image de la gestion de projet - n’apporte-elle pas plus de confusion qu’autre chose ?
TD : Les contours de la gestion de projet sont effectivement rendus flous par le nombre des appellations diverses et variées qui sont apparues. Mais la notion de PSA reste la plus fabuleuse, la plus grande illusion de l’histoire. Le but était de vendre à des intégrateurs, des sociétés informatiques un outil qui leur permettrait de gagner en efficacité. L’idée en soi n’est pas mauvaise, mais encore faut-il s’attarder sur la manière dont sont organisées ces entreprises et plus particulièrement sur leur politique d’investissement en terme d’outil. Elles investissent par rapport à des projets qu’elles refactureront à leurs clients. Imaginer un instant que ces entreprises iraient trouver le temps et l’argent nécessaires à investir dans un outil dont elles seraient l’unique bénéficiaire relève simplement de l’utopie !
En parallèle, le discours marketing proclame le PSA comme l’ERP des sociétés de services informatique. Or ces outils ne couvrent que les fonctions relatives à la vie d’un projet et absolument pas les aspects comptables notamment… cette analogie constitue une colossale erreur marketing. Plus généralement, je pense que la grande erreur marketing commise par les éditeurs de gestion de projets est de s’être laissé enfermé dans les outils de gestion. Cela a favorisé cette surenchère d’acronymes PSA, SRM, etc. Je pense que le bon positionnement est celui des outils décisionnels. La gestion de projet sert à prendre des décisions et ne sert qu’à ça. L’objectif n’est pas de savoir ce qu’il s’est passé la semaine dernière, cette information n’est qu’une infime étape dans le cercle vertueux évoqué tout à l’heure. Nous sommes dans le décisionnel opérationnel au même titre que les outils d’élaboration budgétaire proposés par Hyperion ou Cartesis ou que le CRM analytique.
En parallèle, le discours marketing proclame le PSA comme l’ERP des sociétés de services informatique. Or ces outils ne couvrent que les fonctions relatives à la vie d’un projet et absolument pas les aspects comptables notamment… cette analogie constitue une colossale erreur marketing. Plus généralement, je pense que la grande erreur marketing commise par les éditeurs de gestion de projets est de s’être laissé enfermé dans les outils de gestion. Cela a favorisé cette surenchère d’acronymes PSA, SRM, etc. Je pense que le bon positionnement est celui des outils décisionnels. La gestion de projet sert à prendre des décisions et ne sert qu’à ça. L’objectif n’est pas de savoir ce qu’il s’est passé la semaine dernière, cette information n’est qu’une infime étape dans le cercle vertueux évoqué tout à l’heure. Nous sommes dans le décisionnel opérationnel au même titre que les outils d’élaboration budgétaire proposés par Hyperion ou Cartesis ou que le CRM analytique.
NG : Pensez-vous véritablement que toutes les entreprises aient besoin ou puissent mettre en place une gestion de projet ou y’a-t-il un taille critique ?
TD : C’est un point que nous avions abordé avec Philippe Nieuwbourg. A la question, une PME à-t-elle besoin d’un outil de gestion de projet la réponse est oui ! Dès qu’une entreprise s’interroge sur la manière d’améliorer ou de gagner en efficacité dans la conduite de ses projets, il devient évident qu’elle a besoin d’une solution. Une fois encore, il ne s’agit pas de gérer, mais de décider, d’anticiper, de prévoir… de piloter les projets. Quant à savoir si l’offre est dimensionnée par rapport à la PME la réponse est la même que concernant les chefs de projets. Une PME qui n’a pas de culture de projet ne va pas l’acquérir du jour au lendemain. C’est en pratiquant que l’on devient praticien et c’est en pratiquant la gestion de projets que l’on en acquiert la maîtrise et souvent dans ce cas la préconisation est de commencer sur des modèles simples.
NG : Les solutions permettent-elles cette prise en main graduelle du métier comme de l’outil ou faut-il revenir au couple papier/crayon ?
TD : La fonction peut être informatisé parallèlement à l’usage du papier, crayon. Ce n’est pas incompatible. Certes, dans un premier temps l’entreprise aura une Ferrari entre les mains, dont elle n’utilisera que la première, puis progressivement elle montera en régime. Attention, il ne s’agit pas de prendre une enclume pour écraser une mouche. Mais aujourd’hui, toutes les solutions du marché savent faire des choses simples. Ceux qui vont mettre en œuvre ces solutions, soit les ressources internes des éditeurs, soit les quelques trop rares sociétés de services spécialisées, doivent en revanche faire des efforts pour s’adapter au niveau de compétence de l’entreprise et l’aider à monter en puissance. J’ai pu rencontrer beaucoup d’entreprises dont la culture projet était égale à zéro. Leur objectif n’était pas de savoir comment encadrer un projet d’informatisation, mais bien de chercher à accompagner les projets de l’entreprise : comment les imaginer, comment les supporter dans la mesure ou cette question peut induire une taille critique à atteindre, etc. Les incidences sont nombreuses et fortes.
NG : La gestion des tâches dans Outlook par exemple ne peut-elle fournir un bon compromis ?
TD : Il y a quelques années, j’ai assisté à une conférence à laquelle participait un spationaute allemand. Il nous expliquait que le lancement d’une navette spatiale équivaut à un projet de sept ans. Ce type de projet se décompose en plusieurs dizaines de milliers de tâches et, le plus fou est que 90 % de ces tâches ont une durée inférieure à la seconde. Mais où est l’intérêt de suivre des tâches dont la granularité est inférieure à la seconde. Dans ce cas précis, les enjeux financiers sont certes phénoménaux, mais surtout il s’agit de la vie d’individus. Donc il y a de la pertinence à se préoccuper de tâches même inférieures à la seconde, cela a un sens. Lorsqu’il s’agit de rédaction d’articles, par exemple, planifier la prise de rendez-vous comme une tâche a-t-il un sens ? Je n’en sais rein dans l’absolu. Mais le travail de mise en œuvre consiste également à déterminer la ou les granularités pertinentes par rapport aux projets menés par l’entreprise. Il est tout à fait imaginable de faire co-exister différentes granularités. Le problème n’est pas là, il intervient dans l’aptitude ou non des progiciels à accueillir les projets : entre outil de productivité individuelle tels que Microsoft Project et les solutions de gestion de projets. La distinction se fait dans la capacité à agglomérer des informations, qui doivent avoir un référentiel commun mais pas obligatoirement un comportement commun. Lorsque vous avez des projets dont la tâche élémentaire se mesure en minutes et que parallèlement d’autres projets ont la semaine pour granularité, il faut être capable d’agglomérer l’ensemble des données et c’est précisément là que les limites d’outils comme Microsoft Project, Outlook ou autres sont atteintes.
NG : C’est dans la projection que se joue le pilotage, sachant qu’il est nécessaire de tenir compte de l’ensemble des paramètres si infimes soient-ils ?
TD : Prenons un exemple, aujourd’hui votre outil de gestion de projet abrite les soixante ou soixante-dix projets de votre entreprise sur les trois prochaines années. Lorsque vous condensez l’information, l’outil fait apparaître que dans deux ans vous allez rencontrer une surcharge de travail sur une période de quinze jours. La belle affaire ! Il est inutile de chercher à optimiser la charge de travail sur l’ensemble des projets de manière à mesurer aujourd’hui que cette surcharge sera absorbée. Ce déploiement d’énergie est vain. En revanche, il est important de mesurer qu’il y a potentiellement un risque, à un moment donné de la vie de l’entreprise. Ensuite, la gestion de projet consiste à aider les chefs de projets et les responsables de l’entreprise à minimiser ces risques, à définir les priorités entre les projets pour progressivement réduire le risque. Nous sommes dans une sphère décisionnelle et non dans une logique d’exécution. Nous sommes aussi dans la gestion, dans la mesure ou gérer consiste aussi à prendre des décisions. Il s’agit de voir les projections, d’analyser le passé et d’en déduire les méthodes adéquates. Nous sommes loin de l’image de machine à pointer, couramment employée.
NG : Le principal souci est donc de réhabiliter l’image associée à la gestion de projet… mais quelle est-elle exactement ?
TD : Il y a plusieurs discours. Certains acteurs partent sur l’idée d’économies d’échelle. L’un des principaux postes de coût reste les salariés donc le discours qui repose sur une meilleure gestion des personnels est perceptible. Or cette voie laisse la porte grande ouverte aux ERP. SAP et Oracle se sont d’ailleurs déjà positionnés et la concurrence sera déséquilibrée. Je pense que le vrai terrain concurrentiel doit être celui de la décision et du pilotage.
Après il y a le poids de l’histoire et un effet d’amalgame. Tous les éditeurs ne proposent pas exactement la même chose. La gestion de projet telle qu’on l’entend aujourd’hui elle est née avec le plan Marchal. L’approche très industrielle, est basée sur l’ordonnancement de tâches, une suite logique d’évènements jusqu’à atteindre une finalité. La composante la plus pénalisante est le temps : ne pas lancer la ligne de production au moment prévu, etc. Le système fonctionne très bien dès lors qu’il s’agit de processus industriels. C’est typiquement le monde d’Artemis, il suffit d’ailleurs de consulter la liste de ses clients qui par ailleurs le suivent depuis de nombreuses années pour le constater. C’est également le terrain d’expression d’outils comme Microsoft Project ou de PSNext (LeBihan).
Avec les années 70 et l’informatisation des entreprises, sont apparus d’autres typologies de projets et d’autres besoins. La spécificité de ces projets par rapport aux précédents est qu’il existe une forte dissociation entre les délais et la charge. Selon que vous travaillez en France, en Angleterre ou en Espagne, vous êtes soumis au code du travail local. En France, il stipule qu’une semaine de travail est égale à 35 heures. Le délai c’est une semaine, en revanche la charge de travail potentiel est de 35 heures. Pour ce même délai, la charge de travail serait de 48 heures en Angleterre contre 40 heures en Espagne. Autre particularité, dans la construction d’un bâtiment, si un maçon met une journée à bâtir un mur, en ajoutant un second maçon vous diviser mécaniquement le temps de construction du mur par deux. Ce calcul ne s’applique pas à l’informatique. En l’occurrence, les compétences de chaque individu sont excessivement pointues. Un spécialiste Cobol peut difficilement intervenir sur un projet Fortran. La préoccupation n’est pas tant de démarrer et de finir à une date précise, mais bien la manière dont seront gérées les ressources rares dont la charge de travail potentielle est obligatoirement limitée. Et cette capacité à gérer les délais et les charges est fournie par la seconde génération de solutions dont le plus connu était ABT Corporation devenu Niku i[[ndlr : qui vient d'être racheté par CA]]i . Cette dimension est étrangère à des outils comme Artemis, représentatif de la première génération. Les règles de gestion sont différentes, leur complexité est beaucoup plus forte.
Après il y a le poids de l’histoire et un effet d’amalgame. Tous les éditeurs ne proposent pas exactement la même chose. La gestion de projet telle qu’on l’entend aujourd’hui elle est née avec le plan Marchal. L’approche très industrielle, est basée sur l’ordonnancement de tâches, une suite logique d’évènements jusqu’à atteindre une finalité. La composante la plus pénalisante est le temps : ne pas lancer la ligne de production au moment prévu, etc. Le système fonctionne très bien dès lors qu’il s’agit de processus industriels. C’est typiquement le monde d’Artemis, il suffit d’ailleurs de consulter la liste de ses clients qui par ailleurs le suivent depuis de nombreuses années pour le constater. C’est également le terrain d’expression d’outils comme Microsoft Project ou de PSNext (LeBihan).
Avec les années 70 et l’informatisation des entreprises, sont apparus d’autres typologies de projets et d’autres besoins. La spécificité de ces projets par rapport aux précédents est qu’il existe une forte dissociation entre les délais et la charge. Selon que vous travaillez en France, en Angleterre ou en Espagne, vous êtes soumis au code du travail local. En France, il stipule qu’une semaine de travail est égale à 35 heures. Le délai c’est une semaine, en revanche la charge de travail potentiel est de 35 heures. Pour ce même délai, la charge de travail serait de 48 heures en Angleterre contre 40 heures en Espagne. Autre particularité, dans la construction d’un bâtiment, si un maçon met une journée à bâtir un mur, en ajoutant un second maçon vous diviser mécaniquement le temps de construction du mur par deux. Ce calcul ne s’applique pas à l’informatique. En l’occurrence, les compétences de chaque individu sont excessivement pointues. Un spécialiste Cobol peut difficilement intervenir sur un projet Fortran. La préoccupation n’est pas tant de démarrer et de finir à une date précise, mais bien la manière dont seront gérées les ressources rares dont la charge de travail potentielle est obligatoirement limitée. Et cette capacité à gérer les délais et les charges est fournie par la seconde génération de solutions dont le plus connu était ABT Corporation devenu Niku i[[ndlr : qui vient d'être racheté par CA]]i . Cette dimension est étrangère à des outils comme Artemis, représentatif de la première génération. Les règles de gestion sont différentes, leur complexité est beaucoup plus forte.
NG : Quelles questions doivent se poser les entreprises avant d’orienter leur recherche de solution ?
TD : Certes, avec le bug de l’an 2000, le lancement de l’euro, entre autres, les projets informatiques ont eu le vent en poupe. Mais aujourd'hui une entreprise qui veut passer son organisation en mode projet, ne cherche pas à couvrir ses projets informatiques mais son cœur de métier. En l’occurrence, elle doit se positionner en termes de délai et de charge, sans ce préalable elle va au devant de grandes déconvenues. Si sa préoccupation est seulement de maîtriser le temps, dans ce cas, les outils historiquement basés sur l’ordonnancement remplissent parfaitement la mission. En revanche, si sa préoccupation repose sur la maîtrise du temps et de la charge, elle doit se tourner vers la seconde catégorie de solutions. Bien entendu, des outils de type ordonnancement tels que Artemis peuvent aller sur ce terrain, il y existe des précédents. Mais pour compenser leurs insuffisances par rapport au modèle cible, ils sont complétés par un gros travail de développement spécifique. Le poids du détournement de ce type de solution entache la réputation de ces outils et se répercute sur l’ensemble du marché.
Si je schématise, la maîtrise du temps équivaut dans l’entreprise à la maîtrise d’ouvrage tandis que la maîtrise de la charge correspond à la maîtrise d’œuvre. En position de donneur d’ordre, la maîtrise d’ouvrage veut que le projet débute et s’achève à des dates précises. En revanche, le maître d’œuvre est chargé de mettre la bonne compétence en face de la bonne tâche. Il maîtrise la capacité de travail de chacune de ses ressources qu’elles soient humaines, matérielle, logistique ou autre. Pour que cela fonctionne, il faut mettre en place une structure d’arbitrage face à des zones de conflits qui ne manquent pas d’apparaître simplement parce que les intérêts ne sont pas les mêmes entre le temps et la charge. La gestion de projet touche à l’organisation de l’entreprise.
Si je schématise, la maîtrise du temps équivaut dans l’entreprise à la maîtrise d’ouvrage tandis que la maîtrise de la charge correspond à la maîtrise d’œuvre. En position de donneur d’ordre, la maîtrise d’ouvrage veut que le projet débute et s’achève à des dates précises. En revanche, le maître d’œuvre est chargé de mettre la bonne compétence en face de la bonne tâche. Il maîtrise la capacité de travail de chacune de ses ressources qu’elles soient humaines, matérielle, logistique ou autre. Pour que cela fonctionne, il faut mettre en place une structure d’arbitrage face à des zones de conflits qui ne manquent pas d’apparaître simplement parce que les intérêts ne sont pas les mêmes entre le temps et la charge. La gestion de projet touche à l’organisation de l’entreprise.
NG : Comment déplacer le débat de la gestion vers le décisionnel ?
TD : Ce n’est pas simple. Il y a d’abord les acteurs eux-mêmes. Pas seulement les éditeurs mais les organismes, les syndicats professionnels… Or dans leur grande majorité, 90 % environ, ils sont issus des projets de type industriels. Pour eux les notions de charge et de délais, et leur différentiation, n’existe pas ou relève de l’anecdotique. En France, les écoles d’ingénieurs n’abordent pas le sujet. Il en va de même sur le salon AFITEP, grande messe de la gestion de projet en France.
NG : Finalement le marché se conforte dans son isolement et dans ses clichés ?
TD : Exactement ! Les seuls acteurs à faire du bruit pour sortir de l’ornière sont ceux qui se positionnent sur la distinction entre les valeurs de charge et le délai. Et ils sont peu nombreux : Niku, Planview et Augeo, sachant que le même produit est à l’origine des offres de ces deux derniers éditeurs. Ils sont apparus avec le besoin de piloter les projets informatiques, mais le risque est qu’ils se retrouvent prisonniers de cette étiquette, qu’ils ne parviennent pas à prendre de la hauteur. L’exception pourrait venir de Niku. L’éditeur dispose d’une surface financière solide mais surtout il a la capacité de montrer diverses applications issues d’expériences américaines. Or ses compétiteurs n’ont pas cette possibilité. Aujourd’hui, lorsque Niku parle de gestion de projet, lorsque qu’ils est retenu par une entreprise qu’il s’agisse d’une PME, de grandes banques ou compagnies d’assurances, l’objectif est de passer l’organisation de l’entreprise sur un mode projet dans une démarche de pilotage et de décision. Ce n’est pas le cas des autres éditeurs, pour des raisons de taille ou d’historique. Pour revenir à Artemis, schématiquement l’éditeur est comparable en taille à Niku, ce que ce dernier trouve discutable. Artemis n’est pas à l’aise sur ce discours et explique que la charge est une conséquence du délai. Ces acteurs ne peuvent être moteur de changement, ils placent leurs arguments sur la gestion de portefeuille de projet, etc. Mais si j’applique leur modèle à la lettre, je constate qu’il est inapte dès qu’il s’agit d’introduire la logistique par exemple, comment analyser le véritable coût de mes projets si je ne peux pas tenir compte de tous les paramètres. Ils sont peu nombreux à porter le message, quelques sociétés de service spécialisées, un ou deux cabinets de conseil qui épisodiquement abordent le sujet… mais finalement la plus grande faute revient selon moi aux équipes marketing des éditeurs concernés qui ne s’interrogent pas suffisamment sur ce qu’elles vendent.
NG : L’avenir se trouvera-t-il dans les alliances ou plus si affinité ?
TD : Mon point de vue est que si ces acteurs vont vers les éditeurs d’ERP, ils sont morts et leur marché avec eux. Dans une offre telle que celle de SAP ou de Oracle, la gestion de projet constitue un épiphénomène. Par ailleurs, ces acteurs estiment qu’ils savent faire, au même titre que le décisionnel par exemple. Si je prends BW, il n’est pas parmi les modules les plus performant de SAP. Placé face à un Teradata, la différence se passe de commentaires. Cela n’empêche pourtant pas SAP de vendre BW, et d’être pertinent et écouté… Je vous l’accorde nous sommes dans la comparaison d’un généraliste avec un spécialiste. Mais la logique est la même par rapport à la gestion de projet.
Réorienter la concurrence vers les acteurs du décisionnel est pertinent et salvateur pour les solutions de gestion de projet, hors outils de développement individuel tels que proposés par Microsoft et Le Bihan qui ne permettent pas de répondre au postula décisionnel. Que fait Cognos en rachetant Frango, il achète une technologie, un parc client garant d’une certaine légitimité face à Hyperion et Cartesis, surtout il acquiert la réponse à un besoin décisionnel financier. Si demain un grand acteur du décisionnel rachète Niku par exemple, il élargira sa couverture à la gestion de projet et disposera d’une solution décisionnelle verticalisée, au même titre que la consolidation financière, l’élaboration budgétaire, marketing analytique, etc. i[[ndlr : Cette interview a été réalisée avant le rachat de Niku par CA]]i . Nous sommes loin de tous discours technique, nous parlons de segmentation décisionnelle, du métier de l’entreprise. Si effectivement les acteurs de la gestion de projet prennent cette direction, je pense qu’ils continueront d’exister mais surtout ils sortiront du confinement qui est le leur, pour ne pas parler de zone d’oubli. Ils gagneront en crédibilité, ils pourront se positionner sur des marchés plus importants et seront plus visibles auprès des directions générales de leurs clients. Mais ils doivent aborder la communication sous l’angle métier, les discours de spécialistes sont certes écoutés et compris par des gens, mais ce ne sont pas les directions générales. L’informatique n’échappe pas à la règle, il arrive un moment où il faut faire rêver les gens sinon on ne vend pas… et la technique ne fait pas rêver grand monde.
Réorienter la concurrence vers les acteurs du décisionnel est pertinent et salvateur pour les solutions de gestion de projet, hors outils de développement individuel tels que proposés par Microsoft et Le Bihan qui ne permettent pas de répondre au postula décisionnel. Que fait Cognos en rachetant Frango, il achète une technologie, un parc client garant d’une certaine légitimité face à Hyperion et Cartesis, surtout il acquiert la réponse à un besoin décisionnel financier. Si demain un grand acteur du décisionnel rachète Niku par exemple, il élargira sa couverture à la gestion de projet et disposera d’une solution décisionnelle verticalisée, au même titre que la consolidation financière, l’élaboration budgétaire, marketing analytique, etc. i[[ndlr : Cette interview a été réalisée avant le rachat de Niku par CA]]i . Nous sommes loin de tous discours technique, nous parlons de segmentation décisionnelle, du métier de l’entreprise. Si effectivement les acteurs de la gestion de projet prennent cette direction, je pense qu’ils continueront d’exister mais surtout ils sortiront du confinement qui est le leur, pour ne pas parler de zone d’oubli. Ils gagneront en crédibilité, ils pourront se positionner sur des marchés plus importants et seront plus visibles auprès des directions générales de leurs clients. Mais ils doivent aborder la communication sous l’angle métier, les discours de spécialistes sont certes écoutés et compris par des gens, mais ce ne sont pas les directions générales. L’informatique n’échappe pas à la règle, il arrive un moment où il faut faire rêver les gens sinon on ne vend pas… et la technique ne fait pas rêver grand monde.
NG : Les nouvelles technologies peuvent-elle avoir une incidence sur les acteurs en présence ou sur le marché ?
TD : Clarity de Niku est une solution à 100 % client léger. Je suis plus réservé sur la capacité d’Artemis à passer sur ce mode, Planisware en est à des années lumières, Planview est en train d’y arriver quant à Augeo, il n’y sera certainement jamais. Nous sommes sur des solutions qui opèrent des traitements massifs, des choses lourdes. Tous ces produits ont été conçus à une époque où personne n’envisageait l’idée d’un client léger. Nous étions dans le domaine des traitements répartis, des applications N tiers, etc. Faire la bascule implique une rupture technologique pour l’ensemble des acteurs. Niku par exemple a entièrement réécrit sa solution tout en assurant une compatibilité avec le parc existant. L’investissement demande une assise financière, une puissance de feu dont ne disposent pas tous les intervenants. Augeo n’est pas dans la situation pour le faire, Planisware n’a pas pris ce parti, Planview est en passe d’atteindre l’objectif, Artemis n’y sera pas, sa stratégie quoi qu’il s’en défende reste celle du service plus que de la licence.
Effectivement, la typologie de la clientèle influence le développement des solutions. Je connais une entreprise dans le BTP dont l’informatisation se limite à la comptabilité, aux emails… et dont les commerciaux travaillent avec des bons de commande papier. Pourtant, il s’agit d’une entreprise de mille personnes environ et qui répond à des contrats très conséquents. L’informatique ne pénètre l’entreprise qu’en fonction de ses besoins et suivant cette logique je vous concède que les effets de clients légers n’ont que peu d’emprise quand votre clientèle, votre expérience et votre savoir fait se placent dans un contexte industriel. En revanche, quand vos clients sont des banques, des assurances ou des acteurs des télécoms… si vous n’êtes pas client léger vous perdez en crédibilité. Et cette dicotomie des besoins et des axes de développement n’aide pas à tirer le marché vers le haut, et rend difficile l’apport d’un discours autre que le discours historique. C’est vrai pour la France, mais à l’international le marché est nettement plus dynamique. La littérature anglo-saxonne est fabuleuse.
Effectivement, la typologie de la clientèle influence le développement des solutions. Je connais une entreprise dans le BTP dont l’informatisation se limite à la comptabilité, aux emails… et dont les commerciaux travaillent avec des bons de commande papier. Pourtant, il s’agit d’une entreprise de mille personnes environ et qui répond à des contrats très conséquents. L’informatique ne pénètre l’entreprise qu’en fonction de ses besoins et suivant cette logique je vous concède que les effets de clients légers n’ont que peu d’emprise quand votre clientèle, votre expérience et votre savoir fait se placent dans un contexte industriel. En revanche, quand vos clients sont des banques, des assurances ou des acteurs des télécoms… si vous n’êtes pas client léger vous perdez en crédibilité. Et cette dicotomie des besoins et des axes de développement n’aide pas à tirer le marché vers le haut, et rend difficile l’apport d’un discours autre que le discours historique. C’est vrai pour la France, mais à l’international le marché est nettement plus dynamique. La littérature anglo-saxonne est fabuleuse.
NG : A quoi attribuez-vous ce retard ?
TD : La Grande Bretagne est particulièrement dynamique. D’une part il n’y a pas de barrière de langue mais surtout leur philosophie du travail est différente de la nôtre, une semaine de travail outre Manche c’est 48 heures, pas 35. Autres géographies au dynamisme prononcé, les pays d’Europe du nord. La Scandinavie, le Danemark sont des pays où la gestion de projet, au sens décisionnel du terme, constitue une pierre angulaire dans la gestion des entreprises. La France figure au rang des latins, contrairement à l’Italie qui est en train d’adopter une culture de gestion de projet, l’Espagne également… En terme d’organisation d’entreprise, les Allemands et nous seront peut être bientôt les derniers latins.
NG : Pour revenir au déclencheur de cette interview, pensez-vous que des solutions ovni comme FlexRun* auront un influence sur le marché de la gestion de projet ?
TD : Comparativement à la situation que je viens de décrire, vous comprendrez certainement mieux ma moue dubitative quant à la solution proposée par FlexRun. Je ne vois pas ce que cette solution apporte, ils enfoncent des portes ouvertes. Je ne dis pas que la présentation qu’ils en font n’est pas pertinente et que les deux fondateurs ne rencontreront pas la réussite. Mais l’intérêt en l’état m’apparaît très faible et ils devront faire quelques aménagements parce que passer par de la gestion manuelle via des tableaux Excel avant d’automatiser un processus me semble un peu lourd. Globalement leur idée reste intéressante, même si elle ne couvre qu’une toute petite partie de la problématique. Quand à savoir l’influence qu’ils pourraient avoir sur le marché de la gestion de projet, je suis partagé. Nous avons eu le cas d’un grand compte industriel, l’une des dix premières entreprises du CAC 40, qui a choisi il y a de nombreuses années un produit de gestion de projets. Pour un ensemble de raisons, cet outil ne sert que de pointeuse. A l’échelle de plusieurs milliers d’utilisateurs et compte tenu des développements spécifiques liés aux contingentements sociaux, chacun est capable d’imaginer l’ampleur de la facture. Je vous l’accorde, ce type de projet est aussi symptomatique d’une époque. Je me fais l’avocat du diable, mais le risque potentiellement porté par des produits tels que FlexRun est d’en ajouter à l’image déjà bien terne de ce domaine applicatif. Et à l’inverse, l’association d’idée peut ne pas être faîte puisque contrairement aux acteurs de la gestion de projet, eux se positionnent sur le créneau décisionnel.
