Et si le projet dérapait bien avant les bugs ?
À travers Saussure et Lacan, cet article explore une idée souvent sous-estimée dans les projets de Système d’Information : les plus grands malentendus naissent parfois dans les mots eux-mêmes.
Philippe Viraye
6/1/20265 min read
Et si le projet dérapait bien avant les bugs ?
Il y a quelques semaines, je retombe sur le Cours de linguistique générale de Ferdinand de Saussure.
À l'origine, je cherchais à comprendre les notions de signifiant et de signifié reprises plus tard par Jacques Lacan. Ce n’est pas exactement le type d'ouvrage que nous imaginons au milieu de documents de cadrage, de spécifications ou de comités projet.
Et pourtant...
Dès l’introduction de ce livre, une idée apparaît avec une étonnante modernité : beaucoup de dysfonctionnements dans les projets ne naissent pas uniquement de problèmes techniques, organisationnels ou méthodologiques.
Ils commencent parfois beaucoup plus tôt : dans les mots.
Le mot n'est pas le concept
Saussure distingue deux dimensions dans le signe linguistique :
le signifiant : le mot lui-même, sa forme écrite ou sonore
le signifié : le concept mental associé à ce mot
Il rappelle que le lien entre les deux est arbitraire. Autrement dit, un mot n'a rien d'évident en lui-même. Il ne prend sens qu'à travers une convention partagée par un groupe.
Cette idée aura une influence considérable bien au-delà de la linguistique.
Lacan s'appuiera plus tard sur cette logique du signifiant pour montrer que ce qui nous échappe consciemment reste néanmoins structuré par la langue. Sa formule est célèbre : « L'inconscient est structuré comme un langage. »
=> Ce développement mériterait un article à part entière — il sera l'objet d'une prochaine publication.
Je vous propose de retenir ce que Lacan prolonge à partir de Saussure, et la manière dont cela éclaire certaines situations de projet.
Chez Saussure, le malentendu est d'ordre cognitif : deux interlocuteurs associent des concepts différents au même mot. La solution semble alors accessible : il suffit de clarifier, de définir, de s'accorder sur un glossaire.
Lacan lui complique cette vision. En plaçant le signifiant au-dessus du signifié (l’inverse de la hiérarchie Sausurienne) il montre que les mots ne renvoient pas seulement à des concepts partagés. Ils peuvent porter des investissements inconscients propres à chaque interlocuteur : des attentes, des craintes, des représentations que le sujet lui-même ne formule pas explicitement.
Ce qui expliquerait pourquoi certains malentendus en projet résistent à toute clarification. Quand le métier répète « on veut quelque chose de simple » malgré plusieurs allers-retours, ce n'est pas nécessairement un problème de définition. C'est peut-être que le mot « simple » transporte autre chose : une inquiétude face à la complexité, une méfiance vis-à-vis du SI, ou une expérience passée jamais tout à fait soldée.
Le malentendu n'est alors plus seulement linguistique. Il devient relationnel. C'est précisément là que Lacan devient « utile ». Dans les projets informatiques, certaines incompréhensions semblent fonctionner de manière assez proche. Le malentendu ne vient pas toujours d'un manque d'échange. Il peut venir du fait que chacun croit parler de la même chose parce que les mots utilisés sont identiques.
"Temps réel" : quand tout le monde acquiesce… sans parler du même concept
Dans les projets, certains termes paraissent tellement évidents qu'ils cessent d'être questionnés.
Prenons un exemple classique : le métier demande un traitement "en temps réel".
Autour de la table, personne ne réagit. L'expression semble claire pour tout le monde. Puis vient le moment de la recette.
Le métier découvre des batchs exécutés toutes les heures.
Incompréhension immédiate : "On avait pourtant demandé du temps réel."
Le développeur n'avait pas forcément tort.
Le métier non plus. Car derrière l'expression "temps réel", chacun projetait une réalité différente.
Pour :
Le Métier, il s'agissait souvent d'obtenir une information immédiatement exploitable
Les équipes du Système d'Information, le sujet était plus complexe :
volumétrie
charge
contraintes réseau
performance globale
coûts d'infrastructure
stabilité de l'ensemble du système,...
C'est précisément pour cette raison que les architectures utilisent parfois des traitements programmés (batchés), des files d'attente ou des mécanismes asynchrones. Non pas parce que le besoin métier est ignoré. C'est parce qu'une instantanéité absolue n'est pas toujours techniquement soutenable à grande échelle. Le malentendu devient alors particulièrement intéressant.
Le :
Métier parle d'un besoin fonctionnel
Système d'Information entend déjà une contrainte d'architecture
Le mot est identique. Par contre les réalités qu'il transporte ne vivent déjà plus dans le même espace.
Et ce mécanisme traverse énormément de projets :
"Client"
"Utilisateur"
"Commande"
"Référentiel"
"Fiable"
"Simple"
Des mots utilisés quotidiennement. Mais rarement stabilisés collectivement.
Beaucoup de projets gèrent la parole… sans construire une langue commune
Saussure distingue :
le langage : la faculté humaine de communiquer
la langue : le système partagé de signes et de règles
la parole : l'usage individuel de cette langue dans l'échange
Eclairée sous l'angle des projets Système d'Information, cette distinction devient particulièrement intéressante.
Les organisations consacrent énormément d'énergie à gérer la parole :
réunions
ateliers
comptes rendus
échanges de mails
cérémonies projet
Mais beaucoup moins dans la construction d’une véritable langue commune :
glossaire métier
dictionnaire de données
définitions stabilisées
règles de gestion explicitement partagées
Or sans langue stabilisée, une réunion peut facilement devenir une illusion de compréhension.
Tout le monde parle. Tout le monde croit comprendre. Mais chacun continue parfois à projeter silencieusement ses propres représentations derrière les mêmes termes. Le décalage n'apparaît souvent qu’au moment de la recette. Pire : en production.
Les mots flous : un risque projet sous-estimés
Un autre concept de Saussure éclaire particulièrement bien certaines ambiguïtés fonctionnelles : la valeur différentielle.
Un mot ne prend sens que par opposition aux autres mots du système. « Chaud » n'existe que parce qu'il y a « froid », « tiède », « brûlant ». Sans repères, le mot devient imprécis.
Sans repères, le mot devient imprécis et viennent immédiatement à l'esprit tous ces termes omniprésents dans les projets :
"Urgent"
"Dès que possible"
"Ergonomique"
"Haute disponibilité"
Ces expressions paraissent claires… jusqu'au moment où il faut les traduire concrètement.
"Dès que possible" selon quelle contrainte ?
"Ergonomique" par rapport à quel usage ?
"Haute disponibilité" : 99 % ? 99,9 % ? Sur quelle plage horaire ?
Le problème n'est pas toujours la mauvaise volonté. C'est souvent l'absence d'un cadre partagé permettant de donner une valeur précise aux mots utilisés. Chaque terme laissé dans le flou devient une ambiguïté différée qui réapparaît en recette, en arbitrage, ou en production.
Ce que cette lecture change dans la manière d'observer les projets
Saussure ne propose évidemment aucune méthode de gestion de projet. Mais sa grille de lecture apporte quelque chose de précieux : une vigilance particulière sur le langage lui-même.
Car dans beaucoup de projets, les plus grands malentendus ne viennent pas nécessairement d'un manque de communication. Ils viennent parfois de l'illusion inverse : croire que l'on parle déjà de la même chose parce que les mots sont identiques. Et c'est souvent là que les dérives commencent.
Le livre le plus utile que j'aie lu récemment sur les incompréhensions en projet n'était finalement pas un livre de management.
C'était un cours de linguistique publié il y a plus de cent ans.
💬 Et vous — quel mot a provoqué le plus grand malentendu dans vos projets ?