Les technologies de l’information jouent un rôle central dans la structure moderne des organisations. Elles sont des atouts précieux permettant de réduire les coûts de production et de gagner en compétitivité. Par conséquent, la réussite d’une organisation sur le plan économique est liée au succès des projets qu’elle mène dans le cadre de sa transformation numérique.
Il existe plusieurs façons de déterminer la réussite de tels projets. Dans une étude menée par J. Varajão et A. Trigo sur les critères d’évaluation de la réussite d’un projet, il est montré que les indicateurs de réussite fondés a posteriori sont les plus pertinents. Ainsi, la souscription du client à des services de support ou des opérations de maintenance, voire la contractualisation d’un nouveau projet figurent parmi les meilleurs critères de réussite. Aussi, les auteurs affirment que la majorité des managers interrogés ont atteint les objectifs de réalisation de leurs projets menés récemment. La première constatation faite d’après ce résultat contredit l’idée répandue selon laquelle une grande proportion de projets échoue dans le domaine des technologies de l’information. Or, nous ne qualifierions pas l’époque actuelle d’ère de la transformation numérique, si la grande majorité des projets de développement n’avaient pas des chances élevées de réussite.
Nous sommes en droit de nous questionner sur les raisons qui sous-tendent cette idée, vraisemblablement fausse. Pour tenter de comprendre comment a émergé cette vision du développement du numérique et de la difficulté à mener à bien ces projets, il peut être intéressant selon moi de réfléchir selon l’angle des flux physiques que la réalisation de ces projets requiert.
En ce qui concerne le domaine du numérique, il faut reconnaître que la plupart des projets qui sont réalisés ont un ancrage assez faible sur le monde physique. Du point de vue de la conception du projet, la création ou la mise en place de systèmes et d’outils informatiques ne nécessitent pas, hors cas particuliers, la mobilisation d’une grande quantité de ressources (énergie, matières premières, main d’œuvre diversifiées) comme c’est le cas dans d’autres domaines. L’initiation d’un nouveau projet technologique, même à échelle industrielle, peut se limiter à la mobilisation d’une poignée d’ingénieurs et sa mise en place peut s’avérer relativement rapide. Au contraire, la mise en place d’une ligne de production alimentaire par exemple, nécessite des flux physiques importants, la coopération entre plusieurs corps de métiers différents auxquels s’ajoutent les contraintes dictées par tout un ensemble de normes. Les systèmes informatiques bénéficient quant à eux d’une plus grande flexibilité, mais souffrent de surcroît d’une instabilité accrue.
Du fait d’un faible ancrage sur le monde physique, les projets menés dans le cadre de la transformation numérique des organisations offrent aux concepteurs une liberté d’action sans pareil. Il est donc essentiel que les parties prenantes de tout projet s’accordent autour d’un consensus solide pour éviter que son développement ne soit déstabilisé du fait d’un trop grand degré de liberté. En effet, il est fréquent qu’une organisation choisisse de revoir complètement un outil que certains auront jugé obsolète, bien qu’il soit opérationnel et efficace, pour suivre l’évolution d’autres technologies. Aussi, certains projets de développements ne sont justifiés par rien d’autre qu’un choix purement idéologique. C’est un luxe dont peu de concepteurs peuvent se prévaloir, tout domaine confondu. Serait-ce l’expression pure et simple d’un biais de complexité ? Par conséquent, il existe une multitude de projets différents répondant pourtant à des objectifs fonctionnels comparables que le manque de normalisation et de standardisation des outils de développement a rendu possible en partie, lorsqu’elles n’ont pas été ignorées pour des raisons issues d’une volonté de créer une technologie de rupture.
Le domaine des technologies de l’information suit une dynamique particulière où coexistent des technologies au rythme de développement effréné, avec d’autres projets dont le développement s’est stabilisé avec le temps. La conciliation des deux relève parfois de l’exploit, mais elle s’avère être une tâche périlleuse tant les conséquences de l’introduction d’un bug sont inattendues.
Par ailleurs, si l’évaluation d’un projet intègre des critères relevant de la bonne conduite des opérations, il est logique qu’elle soit impactée négativement par les difficultés rencontrées au cours du développement. Une grande part des problèmes susceptibles de se présenter provient sans doute, de l’instabilité inhérente au monde du développement informatique que nous venons d’évoquer et des choix subjectifs, voire arbitraires des développeurs. Ainsi, il semble raisonnable d’affirmer que les critères d’évaluation utilisés jusqu’ici aient été influencés par un biais de perception. Le projet ne s’est peut-être pas déroulé selon l’idée qu’en avaient l’équipe de développement, mais au demeurant, il peut avoir donné satisfaction au client.
Nous comprenons aisément qu’il est nécessaire pour un chef de projet de disposer de critères lui offrant une vision de l’état d’avancement ainsi que de la conformité du projet vis-à-vis des résultats escomptés. Il s’agit dans l’absolu d’un non-sens, car il n’est pas possible d’évaluer un projet avant même que celui-ci ne fournisse effectivement un résultat tangible. Ces critères évaluent seulement les résultats issus d’une projection théorique définie par les concepteurs pour déterminer l’efficacité d’un composant a posteriori. Cependant, il est difficile de prétendre à une pleine exhaustivité de ces tests. Le coût que cela implique est difficile à justifier pour de nombreux cas d’applications. De plus, en termes d’ancrage physique, il semble plus facile de corriger une erreur informatique que de trouver l’origine d’une panne machine et d’effectuer les réparations sur une chaîne de production, pour reprendre l’exemple précédent. Bien entendu, la tolérance face aux erreurs informatiques varie d’un domaine à un autre. Les critères de succès censés évaluer la bonne conduite des opérations au cours du projet offrent donc au mieux une vision parcellaire des résultats attendus, au pire une vue biaisée par la complexité du système qui n’est autre que la conséquence du fort niveau d’intrication de ces composants.
Toutefois, l’essor de l’apprentissage automatique et notamment des grands modèles de langues dans la sphère économique et technologique apporte une nouvelle dimension à ce problème lorsqu’il est vu sous l’angle des flux physiques. Ces derniers sont soudainement devenus très importants. Cela peut nous amener à revoir les méthodes de développement et de gestion de projet. Mais, si les événements prenaient la tournure légèrement fantasmée par certains individus aujourd’hui, il est possible selon moi, qu’il nous faille redéfinir l’objectif même et le sens attribué à l’évaluation d’un système informatique.
Pour conclure, nous avons tenté d’approcher la notion de perception de réussite d’un projet. Nous avons vu que contrairement à leurs homologues ancrés dans le monde physique les projets de développement qui s’inscrivent dans le monde numérique bénéficient d’une plus grande souplesse. Cette liberté d’action incite les concepteurs à faire évoluer les systèmes qu’ils maintiennent afin de suivre les dernières tendances dans le monde du développement. Le coût d’une refonte du code d’un système informatique en termes de flux physiques est moindre en comparaison du réagencement d’un système de production avec un fort ancrage dans le monde physique. Cela a pour inconvénient de rendre les systèmes informatiques moins stables. Il est donc moins évident d’établir des normes de conceptions rigoureuses et de s’y tenir. L’interopérabilité des systèmes n’est pas garantie et par conséquent le développement s’en retrouve plus difficile. Ainsi, se référer à des critères de réalisation intermédiaires pour suivre le bon déroulement du projet n’offre pas une bonne appréciation de la réussite d’un projet. Dans le meilleur des cas, ils permettent d’évaluer les capacités de l’équipe de développement à effectuer une estimation juste de l’avancement du projet en fonction des bases existantes.