Big Data, Science des données, aide à la décision en entreprise, business intelligence, data warehouse, reporting, OLAP, web analytics, data visualization, data mining, internet des objets, informatique cognitive, intelligence artificielle...

Abonnez-vous gratuitement à Decideo !


Decideo

 


Note de recherche | La gestion de projet relève du pilotage d’entreprise et du décisionnel opérationnel


Rédigé par Barbara Poirette le 17 Juin 2005

La gestion de projet ne parvient pas à passionner les foules ! De concepts novateurs en acronymes fumeux les acteurs semblent toujours chercher leur sésame. Mais dans cette quête de visibilité, n’en n’auraient-ils pas oublié ou négligé les grandes lignes auxquelles la gestion de projet se doit de répondre. Suite à des échanges avec Philippe Nieuwbourg*, nous avons recueilli l’analyse d’un ancien du secteur, Thierry Dupiot, aujourd’hui directeur général de Makhila, société de conseil en optimisation commerciale, sur le marché de la gestion de projet

* « FlexRun, passez de la prise de décision au contrôle de l’exécution », article de Philippe Nieuwbourg, paru le 4 avril 2005.



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, 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.

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 ?

Note de recherche | La gestion de projet relève du pilotage d’entreprise et du décisionnel opérationnel
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.

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.

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 ?

Note de recherche | La gestion de projet relève du pilotage d’entreprise et du décisionnel opérationnel
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.

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.

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é ?

Note de recherche | La gestion de projet relève du pilotage d’entreprise et du décisionnel opérationnel
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.

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.

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.




Commentaires

1.Posté par François Pelissolo le 04/07/2005 15:15
Bonjour,
OPX2 de Planisware est disponible :
- depuis 1998 avec OPX2 TimeCard, une saisie des temps web
- depuis 1999 avec OPX2 Intranet, une version web (client java) en consultation
- depuis 2001 avec OPX2 Intranet, en mode mise à jour
- depuis 2003 avec nos solutions full-web OPX2 IT, OPX2 NPD... qui sont regroupées depuis 2005 sous le nom générique OPX2 Processes
Nous sommes à la disposition de toute personne qui pourrait penser qu'OPX2 est "à des années-lumière" de fonctionner en mode full-web, pour leur proposer de prendre contact avec nos clients, grands comptes ou non, utilisant opérationnellement OPX2 en full-web, depuis plusieurs années (humaines celles-là). Cordialement, François Pelissolo, directeur associé de Planisware.

2.Posté par François Pelissolo le 04/07/2005 15:26
Il me semble aussi utile de préciser, au vu de l'impartialité sujette à caution de certaines informations et jugements cités, qu'un fait quant à lui parfaitement vérifiable est disponible sur http://www.makhila.net : "Pendant les 15 années qui ont précédé la création de sa société de conseil, Thierry Dupiot a travaillé pour des entreprises prestigieuses telles Hyperion, Gupta, Borland ou Niku en occupant des fonctions commerciales et d'encadrement commercial". Cette donnée éclaire quelque peu cette lecture. Je suis bien sûr à votre disposition pour discuter de tout cela.

3.Posté par Barbara Poirette le 06/07/2005 11:04
Je constate que la position de Thierry Dupiot vous a piqué au vif. Quant à l’impartialité de notre interlocuteur… peut on avoir une opinion et être véritablement partial ? Je regrette seulement que votre démarche soit réactive et non constructive. Si votre présentation synthétique de l’offre Planisware relève du droit de réponse, la seconde réaction m’apparaît plus discutable. Outre le fait que Thierry Dupiot appréciera certainement la promotion que vous faîte de son parcours et de Makhila, il semblerait que vous soyez passé à coté du fond : à savoir son opinion sur positionnement et l’évolution de votre marché. Dénigrer Thierry Dupiot au titre de son opinion, ne fera pas avancer le débat et ne clarifiera pas un marché de la gestion de projet qui - et je partage l’analyse de notre interlocuteur - doit se rendre accessible au plus grand nombre et non s’enfermer dans la spécialisation. Il suffit pour cela d’assister à un congrès de l’AFITEP pour s’apercevoir que quiconque n’étant pas rompu à l’exercice n’entend rien aux discours de spécialiste tenus sur les stands. Toute entreprise s’interrogeant sur la mise en place de ce type de solution repart avec ses questions ou en déduit que cette voie n’est pas pour elle. Par ailleurs, j’ai consulté l’ensemble de nos communautés thématiques et notamment celle qui est le plus à même de relayer l’information sur la gestion de projet (Progisphere.com). Or, je ne trouve aucune trace de communiqués, ni plus généralement au sein de la rédaction. Je vous rassure ce point est largement partagé par l’ensemble de vos confrères. Enfin s’il vous prenait l’envie de nous informer, sachez que ma boite mail vous est ouverte et que je nous ne manqueront pas de vous solliciter si l’occasion d’un dossier se présente, cette proposition est bien entendu valable pour vos confrères.

4.Posté par Thierry Dupiot le 09/07/2005 19:03
Monsieur Pelissolo je vous remercie de réagir à cet article car comme le précise Barbara Poirette, l'interêt d'une telle communauté est de communiquer et d'échanger des points de vues.

Néanmoins cet endroit n'est pas un endroit de polémique. Aussi je ne vous répondrais pas ici concernant ma position sur le "fullweb" de telle ou telle solution.

Je suis certain qu'en relisant cet article vous verrez que ce n'est pas le sujet principal de ma prise de position mais plutôt un aspect mineur.

Je suis à votre entière disposition pour discuter directement avec vous à cette fin n'hésitez surtout pas à retourner sur mon site web pour y trouver mes coordonnées.

5.Posté par François Pelissolo le 13/07/2005 08:37
Vos réponses s'entendent sur le fond de votre article, et je comprends que cela soit votre propre préoccupation principale. Néanmoins et même si elles sont cités de manière incidente, je suis obligé de réagir à l'énoncé de contre-vérités sur notre produit OPX2. Vous avez choisi de nous citer, cela n'est donc pas complètement gratuit.

Un usager de google tapant "full-web" et "planisware" trouve cette note de recherche en 2ème position, après notre propre site. Il est donc en droit de penser que ce site, à caractère journalistique, est plus proche de la réalité. C'est ainsi que je réagirais personnellement en tant que lecteur.

Il me semble donc normal d'établir la pure et simple vérité (il s'agit en l'occurrence de FAITS et non d'opinion, car je considère que la notion de "full web" est physiquement vérifiable, par exemple en vous donnant une URL de test si vous le souhaitez). Et d'expliquer au lecteur, forcément interrogatif, pourquoi un point de vue aussi tranché sur notre propre produit a pu être donné par M. Dupiot. Je suis le premier désolé de cette polémique, qui n'a pas de précédent en 10 ans d'existence de Planisware, et ce même si effectivement il n'y a rien de grave. J'invite M. Dupiot à assister à un de nos séminaires gratuits, et à dans la foulée à éclairer les lecteurs sur le caractère "full-web" de notre solution.

Car qualifier cet aspect de "mineur" est un point de vue qui est peut-être le vôtre. Mais quand nous gérons des communautés d'utilisateurs multi-sites allant jusqu'à 10 000 chez des grands du pharma par exemple, ceci est tout sauf un point de détail. L'idéal serait que des visiteurs extérieurs à ce débat donnent leur propre point de vue, cela m'intéresserait vraiment.

6.Posté par François Pelissolo le 13/07/2005 09:10
Puisque Mme Poirette m'invite néanmoins à réagir sur le fond de cet article, j'en dis quelques mots à mon tour. Ce sera forcément simplificateur, car ce sujet est en fait l'histoire de ma vie (professionnelle bien sûr, mais pas seulement), et celle des 80 personnes de Planisware, de nos partenaires, clients, et très probablement de nos concurrents et des clients de nos concurrents.

Mon point commun avec M. Dupiot est d'aimer la gestion de projets. C'est important. Il en trace un portrait relativement désabusé, sur des bases que je ne conteste pas. Je les conteste d'autant moins que c'est sur un constat similaire que nous avons créé Planisware il y a 10 ans. Et nous considérons que tant qu'il y a des déçus de la gestion de projets (ou des déçus des logiciels du domaine), il y a un potentiel de progrès et d'avancée pour des logiciels comme les nôtres.

Je comprends aussi, Mme Poirette, votre point de vue sur les congrès de l'AFITEP (par exemple). Il peut être cependant amendé sur deux points. D'abord sur la pertinence de ce genre de rencontres. On entend aujourd'hui parler (rarement je l'admets) parler de gestion de projets sur des médias ciblés tels que BFM. C'est une bonne chose, et ceci rend nécessaire ce genre de manifestations, malgré tous leurs défauts.

Sur le caractère sans doute technique du discours des interlocuteurs rencontrés sur les stands. J'abonde dans votre sens. Je suis le premier, pris dans le feu de l'action, à tenir un discours trop technique dans certaines situations où cela n'est pas adapté. Mea culpa. Mais nous choisissons les ingénieurs de Planisware sur des critères essentiellement techniques, pour une raison très simple : le rôle de nos spécialistes est d'aider nos clients et nos partenaires à bien utiliser un LOGICIEL. Cela ne veut pas dire que ce ne sont pas d'ingénieurs honnêtes hommes. Mais la réalité du marché fait que nous avons choisi de ne pas venir en interférence avec nos partenaires consultants qui, quant à eux, sont plus en charge du discours "méthodologique" sur les produits. A des sociétés comme Oresys, Unilog, Bearing Point, Asco, Catep... la démarche de maîtrise d'ouvrage, l'adaptation des méthodologies métier telles CMMI, Itil... aux besoins de nos clients. A nos propres consultants et développeurs l'obsession de fournir un outil toujours plus facile à déployer, à configurer, à utiliser, pour résoudre des problématiques variées. C'est un choix qui vaut ce qu'il vaut. Il est bien sûr contestable. Je comprends que vous puissiez être frustrée en vous rendant sur un stand de Planisware si vous espérez rencontrer des "gourous" de la gestion de projets. Nous n'en sommes pas, nous nous efforçons plutôt d'être des gourous du logiciel de gestion de projet.

Pour notre part, je me contenterai de dire que nous sommes une société heureuse. Ce qui veut dire pour moi qu'un marché capable de rendre des gens heureux n'est quelque part pas si mauvais. Je connais aussi plein d'autres gens heureux dans leur travail en gestion de projets, avec ou sans notre logiciel. Plein de gens passionnés. Bien sûr il y a plein de choses à faire pour rendre le domaine plus accessible. Mais c'est normal ! Cette science existe (au moins) depuis la construction des pyramides, à une époque où le knowledge management consistait à emmurer les concepteurs des plans...

Comme j'aime être concret, j'ajouterai deux choses très concrètes en guise de conclusion.

Sur la technicité d'abord. Les 2 derniers sujets sur lesquels j'ai personnellement travaillé hier étaient :
- aider nos développeurs à gagner une demi-seconde dans des temps de connexion web (bien sûr) à notre logiciel entre 2 sites distants. Derrière une demi-seconde peuvent se cacher des tas d'enjeux. C'est passionnant, excitant, et utile.
- discuter taille écran. Il y a toujours des gens pour préférer un écran en résolution 800x600. Personnellement je vous écris sur un écran 20 pouces avec 1600 pixels de large. Ce sujet va sembler ridicule à certains. Pourtant il contient en germe un aspect essentiel : le PROGRES. Chez Planisware, le progrès est notre moteur. Et un de mes plus grands plaisirs est de voir des afficionados du "800x600" adhérer petit à petit à notre propos, quand, modestement, nous lui conseillons de passer son propre écran en 1024x800.

Le deuxième point est, éventuellement, de vous faire comprendre que la technique est néanmoins loin d'être notre seul moteur. Mais cela ne relève pas à mon sens d'un discours écrit, mais par exemple d'une discussion ouverte en face de quelques spécialités culinaires d'ici ou d'ailleurs... Invitation ouverte d'ailleurs à toute personne intéressée par le sujet qui voudrait se joindre à nous.

Nouveau commentaire :
Facebook Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.