L’informatique est-elle encore un enjeu stratégique ?

21 juillet 2003

En mai 2003, la Harvard Business Review a publié un article retentissant (Nicholas G. Carr, « IT does’nt matter »). En réponse, la revue a reçu un flot de courrier qui a été publié dans le numéro suivant (« Does IT Matter ? » Harvard Business Review, juin 2003)[1].

L’art de l’économiste, c’est de formuler des enjeux essentiels de façon simple. Cet art repose sur la pratique de la modélisation. Mais si l'économiste s'exagère la portée de ses abstractions, s’il n'associe pas à la modélisation ouverture d’esprit et vigilance, il court le risque de tourner en rond dans le cercle de ses préjugés[2].

Où réside la stratégie ?

Carr annonce la fin du règne des nouvelles technologies de l’information et de la communication, en un mot de l’informatique. Celle-ci est devenue, dit-il, une « commodity », un bien banal que l’on achète sur étagère puis auquel on ne pense pas plus qu’à l’air que l’on respire. Cela ne veut pas dire qu’elle ne soit pas importante (une personne privée d’air mourrait en quelques minutes), mais seulement que comme tout le monde y a également accès, elle n’est plus un facteur de différenciation et de compétitivité.

Certes, l’entreprise qui prendrait du retard en informatique se mettrait en danger, sa fonction de production n’étant pas conforme à l’état de l’art. Mais celle qui prend de l’avance ne peut plus espérer le même avantage compétitif que celui dont ont profité naguère FedEx, American Airlines, Mobil Oil, Reuters, eBay, Wal-Mart, Dell etc. L’informatique n’est donc plus un enjeu stratégique.

En conséquence, Carr formule plusieurs recommandations : réduire le budget informatique ; n’investir dans des solutions innovantes qu’après que d’autres aient réussi (suivre l'innovation, et non la conduire) ; ajourner les investissements pour tirer parti de la baisse des prix ; s'appliquer à gérer les risques et les fragilités plutôt qu'à rechercher des opportunités.  

Carr réserve le qualificatif « stratégique » aux facteurs de compétitivité et de différenciation qui conditionnent la conquête des parts de marché. Limiter les risques, selon lui, ne relève donc pas de la stratégie. Il révèle ainsi qu'il a une conception purement offensive de la stratégie : mais on peut objecter qu'un stratège qui négligerait la défensive ferait bien mal son métier.

Problèmes de méthode

Carr cite des statistiques dont on peut tirer des conclusions opposées aux siennes[3], car elles montrent à la fois l’importance qu'a prise l’informatique dans le capital fixe et une baisse de prix qui ne peut qu'accroître son efficacité à coût égal. Il est vrai que « now that IT has become the dominant capital expense for most businesses, there is no excuse for waste and sloppiness» (p. 12) ; mais le raisonnement dérape lorsqu’il dit – et c’est le moment clé de sa démonstration -  « IT is, first of all, a transport mechanism – it carries digital information just as railroads carry goods and power grids carry electricity » (p. 8).

Or dire que l’informatique est un pur « mécanisme de transport » c’est négliger l’étape initiale de modélisation des processus et de définition des concepts opérationnels qui lui donne ses fondations sémantiques ; c’est oublier qu’avant d’être transportées les données doivent être inscrites dans une mémoire qu’il faut définir et gérer ; qu’elles sont soumises à des traitements qui les transforment ; c’est enfin et surtout compter pour rien l’assistance que l'informatique apporte au travail humain et l’articulation qu’elle permet entre l’« être humain organisé » et l’« automate programmable doué d’ubiquité ». 

Pourquoi Carr réduit-il ainsi le rôle de l’informatique ? parce que c'est nécessaire à sa démonstration. Pour pouvoir tirer argument de la comparaison avec les réseaux de transport (chemin de fer et électricité), il fallait qu’il affirmât qu’« au fond », « l’informatique n’est que du transport ». Mais ce type de raisonnement constitue, en matière de modélisation, une faute majeure : il implique de réduire la nature spécifique de l’objet considéré à celle d’un objet mieux connu et supposé analogue [4]. Or si l'analogie peut être utile dans l'étape heuristique de la pensée, elle ne peut pas servir à fonder une démonstration.  

Carr fait une deuxième faute lorsqu’il s'appuie sur des statistiques pour prouver que l’informatique n’accroît pas l’efficacité des entreprises. Lorsque l’on veut évaluer l’efficacité d’une technique nouvelle, il faut en effet considérer non l’ensemble de ses utilisateurs mais seulement les plus habiles d’entre eux, ceux qui ont su trouver la meilleure méthode pour en tirer parti, car c’est cette méthode-là qui s’imposera par la suite à tous. Ce n’est donc pas la statistique qu’il faut utiliser dans ces phases de transition, mais la monographie.

Symptôme de crise

Il est vrai que l’on retrouve dans l’article de Carr un écho de ce qui se dit aujourd'hui dans les entreprises et les SSII. Beaucoup de gens craignent que l’informatique ne devienne « le textile du XXI^e siècle », qu'elle soit incapable de fournir des débouchés alors que le conseil se banalise, que des « usines informatiques off-shore » s’installent, que les DSI sont soumis à un fort « turn-over ».

Certes, il y a crise, mais le diagnostic de Carr est-il le bon ? après les deux erreurs de méthode que nous venons d’évoquer, ce serait étonnant.

Ce qu'il dit s’applique aux réseaux télécoms et, de façon plus générale, aux infrastructures du SI (mémoire, puissance, progiciels de base)[5]. Par ailleurs il a raison de dire que l'entreprise doit s'efforcer de maîtriser ses dépenses en informatique[6], se soucier de son degré d'informatisation[7] et des qualités essentielles que son SI doit posséder[8]. Il est vrai aussi qu’elle doit s'appliquer à définir efficacement la frontière de l’externalisation (quelles sont les compétences, les outils que l’on doit conserver dans l’entreprise, quels sont ceux qu'il vaut mieux confier à des fournisseurs externes ? quels sont les programmes spécifiques que l’on doit conserver, les progiciels que l’on doit se procurer ?)

Cependant il ne dit pas qu'il reste beaucoup à faire pour maîtriser le système d'information au plan sémantique au sens large (urbanisation, modélisation des processus, qualité des référentiels, administration des données, professionnalisation des maîtrises d'ouvrage, appropriation du SI par les métiers etc.). Cette dimension du SI a été souvent négligée alors que l'entreprise investissait massivement dans l'infrastructure informatique et télécoms (ce constat est évoqué dans plusieurs des réponses à son article [9]).

Si l'on admet que la difficulté principale réside dans la sémantique du SI, les priorités ne sont plus d'ordre technique[10] mais d'ordre philosophique (la sémantique est affaire de concepts, de pertinence, d’adéquation de la pensée à l’action) et sociologique (comme la maîtrise des processus touche à l'organisation, elle pose des problèmes aux personnes comme aux corporations).

Or les progrès de l’entreprise sur les plans philosophique et sociologique sont plus laborieux que les progrès techniques :
- ils supposent un effort collectif de la part de personnes qui n'y avaient pas réfléchi auparavant (alors que le cercle des techniciens aux compétences pointues est étroit) ;
- les entreprises ont pris la mauvaise habitude de mépriser la philosophie que les ingénieurs qualifient de « baratin » ;
- les philosophes eux-mêmes se sont peu intéressés à l’entreprise, si ce n’est pour la dénigrer ou (plus rarement) pour en faire  l’apologie, démarches également dogmatiques et qui souffrent des mêmes défauts de méthode que celle de Carr. .

Les changements de savoir-faire et de savoir-vivre qu’implique l’informatique nous occuperont pendant la majeure partie du XXI^e siècle. Ils ne se feront pas sans casse car le refus des changements peut être violent. Ce point de vue là ne s'est pas exprimé - si ce n'est de façon implicite - dans l'échange de courriers qui a suivi l'article. Cela surprend un peu.