J'ai du mal à savoir où la technique devient technologie en développement logiciel.
Le mot technologie est utilisé à toutes les sauces,
des "nouvelles technologies" (qui ne sont plus si nouvelles) aux
pseudo-technologies dont l'acronyme cache le vide. De plus, la définition de
technologie comme un mélange technique+science+industrie-secouez-bien ne me paraît
pas pertinent dans ce contexte.
Note: J'écris cela maintenant avant que mon point de vue ne change éventuellement
en continuant de lire [7].
Partons de ce qui représente un exemple parfait de technologie,
de mon point de vue: un lecteur de DVD. Sans conteste il s'agit d'un
objet technique, disons un objet dans lequel sont inscrites des techniques,
mais plus encore j'y vois de la technologie pour les raisons
suivantes: Il y a de l'électronique dedans, donc il y a eu de la recherche
et des travaux scientifiques menant à fabriquer cet objet, par un processus
qui doit être maîtrisé. Il existe de multiples exemplaires du même lecteur,
donc un processus industriel pour le fabriquer. Enfin, et peut-être surtout,
je ne connais pas tous les détails de son fonctionnement et je n'ai aucun
moyen d'intervenir dessus. C'est une sorte de boîte noire avec une interface.
Un point important est que les programmes informatiques contenus dans
ce lecteur DVD ne sont pas le signe d'une technologie en ce qui me
concerne, sans doute parce que je comprends en gros comment ça
marche, de par mon métier, mon expérience et mes connaissances même vagues
dans ce domaine.
Cela m'amène à me rendre compte que je ne considère jamais les logiciels comme
des technologies, mais plutôt comme des objets techniques dont je pourrais
éventuellement m'approprier le fonctionnement, voire le modifier, pour
peu que j'aie accès au code source, et en tout cas je pourrais apprendre
et ne pas être seulement dans un rôle d'utilisateur/consommateur.
Cependant, j'ai récemment dû encadrer le travail d'un développeur sous
Windows utilisant notamment ASP.net.
Et pour une fois, j'ai eu l'impression d'avoir affaire à une technologie. Par
parce que les principes derrière ASP.net sont extrèmement avancés ou que je ne
les comprenais pas, mais simplement parce que je n'avais aucune possibilité
de modifier cet objet technique, de le saisir, l'étudier, le dériver, ...
Il me semble que je vois cet objet comme une technologie parce que c'est
une boîte noire et qu'elle ne présente aucun potentiel d'évolution. C'est
un objet technique figé. C'est normal puisqu'il s'agit que cette technologie
puisse être présente sans modification sur des milliers de machines et en
faire une base stable pour des développements, ce qui lui confère un caractère
industriel.
C'est donc l'aspect figé qui me semble caractériser la technologie. Pour qu'une
évolution ait lieu, pour qu'une nouvelle technologie émerge, il faut repartir
de la technique originale ayant "enfanté" la technologie, et la faire évoluer
pour qu'elle enfante une nouvelle technologie. Une sorte de généalogie en quelque
sorte. Ainsi, la technique du laser "enfante" le lecteur DVD.
Pour illustrer, on peut prendre l'image des familles de langages de programmation:
Un nouveau langage est souvent défini à partir des concepts et des
techniques utilisés dans un précédent langage, mais pas à partir des compilateurs
du précédent langage.
L'utilisation du terme technologie quand on parle d'un langage de programmation,
d'un outil ou d'une bibliothèque de développement, me semble donc induire une
forme de renoncement à en savoir plus, une perte volontaire de maîtrise,
une prolétarisation volontaire.
Un logiciel est donc une technologie notamment par le regard qu'on porte sur lui.
De plus, si c'est accepter le caractère figé qui fait d'un logiciel une technologie,
cette stabilité n'est qu'une illusion: une technologie en version 1.0 sera remplacée
par une autre en version 2.0. Dépendre d'une technologie, c'est prendre
le risque que tout le développement d'un logiciel soit contraint par cette dépendance.
Avoir la possibilité de s'approprier un objet technique logiciel, comme c'est le
cas pour les logiciels libres, c'est au contraire d'une part ouvrir la possibilité de
faire évoluer cet objet pour ses propres besoins et d'autre part être en mesure
de percevoir les orientations de son développement pour l'anticiper.
Quand j'entends des développeurs dire qu'ils utilisent telle ou telle technologie,
quand je vois des offres d'emploi lister les technologies qui doivent être
maîtrisées (ah ah) par le candidat, j'ai du mal à comprendre comment le métier
de développeur logiciel est envisagé, sinon comme une sorte de consommateur
de technologies.
En pratique, cependant, le temps, ou plutôt le manque de temps
rapproche les logiciels libres (comme objects techniques) et les logiciels
propriétaires (comme technologies): même si j'en ai la possibilité, je n'ai
pas le temps d'étudier tous les logiciels libres que j'utilise. Je me retrouve
donc à développer des logiciels par-dessus d'autres logiciels libres,
comme d'autres développent des logiciels par-dessus des "solutions" (ah ah)
propriétaires. On peut faire un parallèle avec les "apéros" Facebook qui sont des usages
qui viennent par-dessus Facebook, réseau social dont les utilisateurs
n'ont pas la possibilité de modifier ni d'en connaître le fonctionnement.
La différence, c'est qu'avec le logiciel libre je ne suis pas seul. Et s'il
y a un bug ou une évolution nécessaire, d'autres peuvent le faire et
reverser au pot commun. Le manque de temps crée de la solidarité, quand
les utilisateurs de logiciels propriétaires restent seuls perchés
sur leur pile technologique. Et plus la pile est haute, plus la précarité
des développements réalisés augmente. Et avec elle, la précarité des
développeurs qui n'ont pas la main sur la construction de la pile.