En résumé :

Dans cette lettre ouverte aux clients et toute personnelle, Allan dit tout haut ce que certains pensent tout bas et expliquent pourquoi les projets informatiques ne se déroulent pas toujours bien pour l’ensemble des parties concernées.

Chère client, cher client,

Je pense qu’il est temps que nous, qui sommes dans l’industrie informatique, soyons clair sur la manière dont nous vous facturons, pourquoi nos factures sont quelques fois un peu plus élevées que ce à quoi vous vous attendez, et pourquoi le résultat de certains projets informatiques sont une déception. La vérité est que lorsque nous commençons un projet informatique, nous ignorons la durée et la quantité d’efforts nécessaire pour le réaliser. Par conséquence, nous ne savons pas combien cela va coûter. Ce n’est peut-être pas le genre de message que vous aimez entendre, particulièrement si vous êtes absolument certain de savoir ce que vous voulez.

Voici une autre vérité que je vais essayer d’énoncer aussi poliment que possible. Vous êtes, après tout, un client, et, sincèrement, je ne voudrais pas vous offenser. Vous connaissez l’adage “Le client a toujours raison” hein ? Le fait est, que vous ne savez pas vraiment ce que vous voulez. Vous pouvez le savoir de manière générale, mais le diable est dans les détails et plus vous essayez de nous donner de détails en amont, plus il est probable que vous voudrez changer d’avis. Chaque fois que vous nous donnerez davantage de détails, vous livrez de futurs otages dans l’inconnue.

Capers Jones, expert en ingénierie logicielle, estime que ce que vous voulez (les “exigences” comme vous aimez les appeler) changent de 2% par mois. Personnellement, je suis surpris que ce chiffre soit si bas !

Juste histoire de compliquer les choses, le monde est incertain. Les choses changent, et des entreprises font faillite. Vous rappelez-vous d’Enron ? de Lehman Brothers ? Les goûts des clients changent. Vous rappelez-vous de Cabbage Patch Kids ? Les modes changent, les gouvernements changent, et les concurrents font de leur mieux pour vous rendre la vie difficile. Donc, même si vraiment, vous savez vraiment ce que vous voulez lorsque vous parlez avec nous la toute première fois, il est peu probable que cela demeure inchangé très longtemps.

Je dois malheureusement vous dire que certaines personnes dans l’industrie informatique prendront avantage de cette situation. Ils vous feront un sourire et vous diront qu’ils sont d’accord avec vous lorsque vous leur direz ce que vous voulez, jusqu’au moment où vous signerez. À partir de là, ce sera une autre histoire ; ils savent que les changements sont inévitables, et ils prévoient de faire un profit substantiel des demandes de changements et des ajouts tardifs à votre dépend.

Pour être tout à fait honnête, il est vrai que nous embellissons quelques fois les choses. Vous pourriez ne pas avoir besoin d’un entrepôt de données pour votre site marchand dès le début. Oui, en effet, certains de nos ingénieurs aiment en faire plus que nécessaire, et oui, nous avons un intérêt direct en ajoutant ce genre de choses afin de vous facturez davantage.

Il est vrai également qu’il est légitime vous pensiez à des besoins et à des fonctionnalités que vous voudriez avoir après que nous ayons commencé. Naturellement, vous considérez que cette chose est “dans” le périmètre alors que nous considérons qu’elle est “en dehors”. Et, dans un esprit d’ouverture, pouvez-vous dire honnêtement que vous n’avez jamais essayé de nous faire gober ça ? (Ce n’est pas le moment de parler des bogues maintenant ; ça va seulement compliquer les choses.)

Franchement, étant donné tout ça, il est presque touchant que vous ayez autant foi en la technologie de vous livrer quelque chose. Mais, lorsque l’informatique livre vraiment quelque chose, eh bien mon gars, ça ne livre pas de la gnognote. Regardez donc ce qu’ont pu faire Bill Gates et Larry Page, ou Amazon ou FedEx. Ne trouvez-vous pas intéressant de voir que lorsque l’industrie informatique développe quelque chose pour elle-même, cela puisse aboutir à des multi-millionnaires. Et lorsque nous développons pour d’autres, ils finissent par perdre de l’argent.

Comment cette conversation a-t-elle pu nous mener jusque-là ? Bref, nous empaquetons tout ce bordel invisible et essayons de vous le vendre. Pour faire ça, nous devons cacher toutes ces choses un peu moches. Nous commençons avec un rituel dénommé estimation - c’est-à-dire combien de temps nous pensons que le travail va prendre. Ces “estimations” sont à peine mieux que des suppositions. Les êtres humains ne savent pas estimer. Nous savons cela depuis la fin des années 70 avec “l’illusion de la planification” décrite par Kahneman et Tversky et qui fut récompensé plus tard par un prix Nobel. À la base, les êtres humains sous-estiment constamment la durée que prendra un travail et sont excessivement confiant dans leurs estimations.

Histoire d’empirer les choses, nous avons une fâcheuse habitude dont nous devrions vraiment nous débarrasser. Entre le moment où nous estimons le travail à faire et celui où nous le faisons, nous changeons d’équipe. Les estimations sont faites par l’équivalent informatique de Manchester United ou des New York Mets, mais l’équipe qui fait vraiment le boulot se rapproche plus d’un patchwork de quatrième division de développeurs, d’analystes et de responsables qui ne se sont jamais rencontrés auparavant.

Les données historiques - les données sur les estimations, les données sur le réalisé, les coûts, etc - peuvent nous permettre d’obtenir une planification éclairée, mais la plupart des entreprises ne possèdent pas ce type de données. Pour celles qui les possèdent, la plupart sont plus qu’inutiles. En fait, Capers Jones indique que des données historiques incorrectes sont la principale source de l’échec d’un projet. Par exemple, les ingénieurs en informatique sont rarement payés pour leurs heures supplémentaires, ce type d’informations n’est donc pas suivi. En effet, certaines entreprises interdisent à leurs employés de se connecter à leurs systèmes en dehors des plages horaires autorisées.

Donc, nous faisons cette supposition (pardon, estimation) et la doublons - nous pourrions également la tripler. Si ce nouveau nombre semble trop élevé, nous pouvons le baisser. Une fois que nos ingénieurs auront fini de peaufiner le nombre, nous le donnons aux commerciaux, qui le peaufinent encore plus. Après tout, nous voulons que vous disiez oui au plus gros prix que nous puissions proposer. Cela peut sembler affreux, mais rappelez-vous : nous aurions pu avoir supposé de manière plus élevée dès le début.

Je vous en prie, ne tirez pas, je ne suis que le messager.

Nous ne savons pas quel nombre est le “bon”, mais pour vous le rendre acceptable, nous prétendons qu’il est fiable et nous en prenons le risque. Nous pouvons uniquement faire ça si le nombre est suffisamment élastique (et, même dans ce cas, nous restons dans le faux). Si le risque ne survient pas, alors notre profit sera énorme. S’il se réalise, nous n’aurons aucun profit et nous pourrions même encourir une perte. Si ce n’est vraiment pas bon, nous n’aurons rien du tout et nous pourrions même finir au tribunal ou être fichu.

L’alternative est que vous preniez le risque - et le bordel qui va avec - et le fassiez vous-même. Malheureusement, autre mauvaise nouvelle : l’informatique interne s’avère souvent pire que des fournisseurs spécialisés. Pour une entreprise informatique, savoir développer est une compétence essentielle. De telles entreprises vivent ou meurent par leur capacité à livrer des logiciels et si elles le font mal, elles meurent. L’évolution élimine les entreprises peu performantes.

L’informatique interne d’entreprise d’un autre côté détruit rarement l’activité de celle-ci, même si elle peut en faire diminuer les bénéfices. En effet, les recherches faites par Caper Jone indique également que les fournisseurs spécialisés font généralement mieux que l’informatique interne.

Dans certains cas, les commerciaux peuvent être absents, mais l’ensemble du processus d’estimation est en mode “faites vos jeux” de la part de différentes sources et pour différentes raisons. Le but ultime est que si vous décidez de prendre le risque, vous pourriez augmentez en fait ce risque.

Je sais que cela peut paraître un scénario perdant - perdant. Vous pourriez simplement rester passif et attendre que Microsoft ou Google résolvent vos problèmes avec une solution prête-à-l’emploi, mais est-ce que vos concurrents vont attendre pendant que vous le ferez ? Serez-vous toujours en activité lorsque Google produira une solution gratuite ?

Ah au fait, faites attention aux charlatans vendant des applications sur l’étagère. Une fois que les personnes commencent à parler de “paramétrage” ou de “configuration”, vous mettez le pied sur une pente savonneuse. Configurer une grosse installation SAP n’est pas une question de sélection d’outils, d’options ou de cocher une case. Configurer de larges systèmes est une activité majeure de développement informatique, peu importe ce que l’on ait pu vous dire. Les personnes qui entreprennent la configuration peuvent se faire appeler des “consultants”, mais ce sont en fait des développeurs informatiques spécialisés.

Il n’y a pas véritablement de solution simple et élégante à cela. Nous ne pouvons pas résoudre ce problème pour vous. Nous avons besoin de vous, mais vous devez travailler avec nous. En tant que client, vous devez vous préparer à travailler avec nous, le fournisseur, encore et encore afin de réduire le risque. Gérer les risques en temps et en heure et économiquement implique des décisions et des concessions au niveau métier. Si vous n’êtes pas ici pour aider, nous pouvons soit faire la solution pour vous (en ajoutant le risque que vous niez) soit nous dépenserons votre temps et votre argent pour le régler.

Vous devez être préparé à accepter et à partager le risque avec nous. Si vous n’êtes pas préparé à prendre des risques, nous allons vous facturer un maximum pour le risque que nous prenons.

Partager le risque a pour effet de réduire le risque, parce qu’une fois que le risque est partagé, vous, le client, êtes motivé pour réduire le risque. Un des risques majeurs dans les projets informatiques est le manque d’implication du client. Vous pouvez aider à cela simplement en restant impliqué.

De manière ultime, tous les risques sont votre risque. Vous êtes le client et vous payez pour ce projet, d’une manière ou d’une autre. S’il échoue à livrer de la valeur, c’est votre activité qui en souffrira. Lorsque vous partagez les risques et êtes impliqués étroitement dans ce processus, les risques peuvent être gérés immédiatement plutôt qu’être laissés ouvertement à pourrir et à grandir.

Au final, vous pouvez avoir de grandes ambitions, mais nous devons travailler petits bouts par petits bouts. Je sais que cela ne semble pas vraiment sexy, mais la création logicielle fonctionne mieux petits bouts par petits bouts. L’économie d’échelle n’existe pas. En fait, nous avons une déséconomie d’échelle, donc nous devons travailler par petits bouts encore, encore et encore. Si vous êtes prêts à accepter ces suggestions, alors appuyons ensemble sur le bouton de remise-à-zéro de notre relation et poursuivons un peu plus notre discussion.

Bien cordialement.
L’industrie informatique.

Auteur : Allan Kelly
Source : Dear Customer: The Truth about IT Projects
Date de parution originale : 13 Mars 2012

Traducteur : Nicolas Mereaux
Date de traduction : 22/01/2018

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.