Une certaine idée du développement

Développer, ce n’est pas juste écrire du code. C’est choisir des outils, adopter des postures, transmettre des intentions. Ce texte rassemble des fragments, des observations, des moments clés rencontrés au fil du temps. Il interroge nos habitudes, nos responsabilités, et les effets parfois inattendus de ce que nous concevons. Il ne cherche pas à conclure, seulement à rouvrir la question : que faisons-nous vraiment, quand nous développons ?

Connexions fondatrices

Avant tous ces langages modernes auxquels nous avons accès, avant cette multitude de frameworks ou de librairies disponibles, avant cette immédiateté devenue norme, cet usage du temps réel, cet enchaînement continu et presque incessant d’informations qui nous maintient hyperconnectés, il y a eu un autre temps…

… un temps de découvertes tâtonnantes, de connexions fragiles, de modems 2 400 bauds, puis de 9.6, 14.4, 28.8 et enfin de ce fameux 56K qui nous donnait l’impression d’atteindre enfin quelque chose de solide, presque confortable. Et ce son grinçant, reconnaissable entre mille qui ouvrait la porte vers un monde encore flou, mais déjà étrangement réel. On se connectait sans vraiment saisir que l’on franchissait une frontière. Celle du temps, de l’espace, des usages. Entre nous, on se recommandait des livres incomplets qu’on lisait jusqu’à l’os. On bricolait sur des machines sous OS2 Warp ou Mac OS 6, puis 7, sur Quadra, qui faisaient tenir tout un monde dans une poignée de kilo-octets.

Nous n’étions pas encore des développeurs web, mais plutôt des bricoleurs. On touchait à tout. On explorait. On bidouillait. On reliait les morceaux.

Entre 1987 et 1993, quelques figures croisées sur ce chemin ont marqué un basculement silencieux, profond. Non pour avoir “réussi”, mais pour avoir su transmettre, sans filtre, une confiance rare.

D’abord, Christopher Hull. Alors qu’en France, on riait encore à l’idée de lire de la vidéo sur ordinateur, préférant miser sur le minitel, ou la télévision hertzienne haute définition, lui il développait QuickTime chez Apple. Plus tard, il contribua à la conception de Netscape, alors que le monde découvrait à peine Mosaic, puis prit part au développement de la Kindle chez Amazon. À chaque étape, il posait un regard rare sur le code : un matériau à façonner, à sculpter. Passer de C++ à Java, disait-il, c’était comme changer de carburant : l’essence ou le diesel, mais la route reste identique. Le langage n’était jamais pour lui une fin, seulement un médium. Une manière d’ouvrir, pas d’enfermer.

Et puis, Paul Van der Hoof, mathématicien passionné de matériel et d’algorithmie, qui m’a offert un Quadra 900 avec 256 Mo de RAM et un 21 pouces Radius, alors que les Macintosh vendus sur le marché eux, étaient équipés de disques durs de 40 mégaoctets et d’écrans 13 pouces. Ce n’était pas du mentorat. C’était une véritable attention.

Et puis il y avait OPAMP, à Los Angeles. Une librairie minuscule, presque clandestine, où circulaient des manuels que personne ne comprenait vraiment, mais que tout le monde dévorait. On n’y cherchait pas des réponses. On y apprenait à mieux formuler les questions.

Ce temps-là n’avait rien pour sembler idéal. Il était lent, imparfait, parfois confus. Mais il portait en lui une forme d’écoute. Le code n’était pas encore un produit. C’était un geste.

Premiers outils, premières postures

Il ne s’agit pas de dresser une chronologie. Ni de célébrer une époque. Mais simplement de reconnaître que les outils que nous utilisons dessinent plus qu’une méthode : ils tracent une posture. Il y a eu HyperCard, Director, puis PageMill, HomeSite, et d’autres. Tous portaient en eux une promesse. Une direction à suivre, ou à détourner.

Avec HyperCard, nous avons découvert l’interactivité. Avec Director, nous l’avons approfondie, structurée, rendue plus précise, avant même que le mot ne devienne un standard. Avec HomeSite, nous avons écrit du HTML 2.0 puis très vite du HTML 3.0 à la main, dans un monde où le WYSIWYG balbutiait. Et aujourd’hui, nous utilisons Vue.js ou React, non pour coder plus vite, mais parce qu’ils modèlent déjà une certaine manière de penser l’application. Ce ne sont pas juste des boîtes à outils. Ce sont des architectures mentales.

Et parfois, c’est bien là que le risque s’infiltre. L’outil déjà façonné, avec sa logique encapsulée, peut finir par parler à notre place. Nous suivons ses conventions, sans toujours les interroger. Or il n’y a pas de neutralité. Chaque structure, chaque syntaxe, chaque cycle de vie suggère une manière d’agir, de résoudre, voire de juger ce qui serait “bien fait”.

Ce n’est pas grave en soi. Mais c’est à observer. Car à force de gagner du temps, nous pourrions finir par perdre le nôtre.

Peter Small, éclaireur latéral

Il n’était pas connu du grand public. Pas de conférence TED, pas de photos en couverture. Et pourtant, Peter Small a ouvert bien plus que des outils. Il a ouvert des perspectives. Il a dit qu’on pouvait penser autrement, depuis le code, mais aussi au-delà de lui.

Ses livres – Lingo Sorcery, Magical A-Life Avatars, The Entrepreneurial Web – formaient un triptyque. Une manière de relier les objets, les agents, les intentions. Ce n’était pas de la technique, ce n’était pas non plus de la philosophie. C’était un tissage. Une sorte de carte mentale, écrite à plusieurs, corrigée en direct par ceux qui le lisaient, le contredisaient, le poussaient à aller plus loin. Parmi ses idées phares de l’époque, l’une frappait par sa clarté : ce n’est pas l’application qui est au service du document, mais le document qui doit servir l’application. Et il faut se rappeler qu’alors, XML n’existait pas encore… quant à JSON, n’en parlons même pas.

Il aimait aussi illustrer ses concepts par des images simples, pour tenter de qualifier et de donner forme à la découverte d’un web encore immature à cette époque.
Imaginez un champ avec un trou, dans lequel il faut lancer une bille. Un observateur indique “trop fort” ou “trop à droite”, et l’on ajuste le tir suivant. Sauf qu’avec le web, le trou change de place à chaque lancer.

Ou encore : C’est comme suivre une voiture dans le brouillard. Celui qui est derrière s’impatiente, klaxonne pour accélérer. Jusqu’au moment où la voiture de devant s’écarte… et que l’impatient, obligé d’ouvrir la route, termine dans le jardin d’une maisonnette.

Il avait mis en place un “café virtuel” – un vrai lieu d’échange, à distance, mais habité. On y croisait des développeurs, des scénaristes, des artistes, des gens de passage. Ce n’était pas un forum. C’était un espace poreux, où chaque remarque pouvait modifier un chapitre en cours d’écriture. C’était vivant. Incertain. Éclairant. [ CAFE – Common Access For Everybody ]

Il ne s’agissait pas de suivre une méthode. Il s’agissait de s’accorder le droit de ne pas tout savoir. De chercher à plusieurs. De comprendre l’invisible entre les lignes. De remettre en jeu ce qu’on croyait acquis.

Peter Small ne donnait pas de leçon. Il allumait des veilleuses.

Comprendre avant de coder

Nous avons tous connu ce moment : le projet démarre, les écrans s’alignent, les délais pressent. Avant même que la lumière de l’écran ne s’allume c’est notre reflet que nous voyons, sur le noir de la dalle. Vu par notre cerveau, ce reflet interroge : entamons-nous un dialogue avec nous-même ? Avant même de taper la première ligne de code, une autre question surgit : pour qui et pour quoi codons-nous ? Et que cherchons-nous à faire, au fond ? On pourrait se jeter sur le clavier, poser les premières lignes, appeler les composants. Mais alors quoi ? Sommes-nous déjà en train de répondre, ou simplement de nous parler à nous-mêmes ?

Trop souvent, le code devient la réponse par défaut. On salue la réactivité, la vélocité, la capacité à produire vite. Mais une solution rapide, à côté du besoin, reste un leurre. Et plus elle est bien empaquetée, plus elle peut faire illusion.

Il faudrait pourtant commencer autrement. Par le besoin. Non pas celui qu’on nous formule, mais celui qu’on entend, entre les lignes. Comprendre le contexte, les non-dits, les tensions d’usage. Trop souvent les designers proposent une interface ou un visuel avant même que la fonction n’ait été définie. Il faut pourtant commencer par poser des hypothèses. Revenir à la fonction, à l’intention. L’interface viendra plus tard. Le code, lui, est là pour écouter, relier, répondre. Cette manière de laisser l’usage guider l’écriture du code, plutôt que l’inverse, rejoint ce que nous développons dans Tracer des solutions, du code à l’usage, où la logique naît du terrain avant de se transformer en outil.

Ce n’est pas une simple méthode. C’est une disposition, une manière d’habiter le travail. Non comme une suite de tickets à clôturer, mais comme un engagement à comprendre. Un projet bien compris limite les erreurs techniques, mais surtout les malentendus humains.

Développer, ce n’est pas répondre. C’est avant tout écouter.

Pour qui et pour quoi codons-nous ?

Il arrive que le geste prenne le dessus. Le plaisir d’enchaîner les lignes, de résoudre un bug, d’optimiser une requête ou de fluidifier une animation. Ce moment où l’on code pour coder, presque comme une danse réflexe, portée par l’élan. On code, on assemble, on optimise. Mais à force de faire, la question finit par resurgir : pour qui codons-nous ? Et, plus troublant encore : pour quoi codons-nous ?

On nous parle d’utilisateur, de cible, de persona. Mais bien souvent, ce que nous fabriquons ne s’adresse plus à quelqu’un. Cela s’adresse à une mécanique. Un flux, un tunnel, un segment. On code pour un parcours d’usage, pour un taux de conversion, pour un besoin défini à distance. Ce n’est pas faux. Mais ce n’est pas tout.

Car derrière chaque clic, chaque interaction, certes, il y a une personne, mais aussi un appareil, un contexte, une contrainte. Quid du Responsive Web Design. Il peut y avoir une connexion lente, un écran peu lisible en plein soleil, un handicap visuel, moteur ou cognitif. Et le code, même s’il reste invisible, a le pouvoir d’ouvrir ou de fermer. De fluidifier ou d’entraver. D’écouter ou d’imposer. Il a aussi le pouvoir de ne pas rendre accessible, de bloquer sans le vouloir, d’exclure par défaut ce qui n’a pas été pensé.

Et puis il y a cette autre question, plus intime : codons-nous pour répondre à un besoin, ou pour justifier notre place ? Codons-nous pour rendre service, ou pour entretenir le système ? Le code peut être un outil. Il peut aussi devenir un écran qui brouille, qui simplifie à l’excès ou qui masque ce qui est en jeu. Des limites d’accès, des comportements inattendus, des règles arbitraires ou des biais non corrigés, peuvent rester cachés. On peut croire que tout fonctionne, alors qu’une partie reste invisible, inaccessible, ou même injuste. Ce n’est pas toujours voulu. Mais c’est là.

Rien n’oblige à choisir un camp. Mais tout invite à rester lucide. Car ce que nous codons agit. Et parfois, sans qu’on le veuille, cela agit sur l’utilisateur, cela agit sur nous.

La donnée : or noir ou poison lent ?

Avant même de parler de données personnelles, nous avons appris à enrichir nos pages de balises sémantiques, d’attributs d’accessibilité, de métadonnées et mots clés pour les moteurs, ou de vocabulaires contrôlés. Autant d’éléments conçus pour mieux transmettre… mais aussi pour mieux capter. Longtemps, la donnée a été vue comme un indicateur. Une trace utile, un appui pour mesurer, comprendre, corriger. Elle servait à améliorer un site, à affiner une fonction, à ajuster un service. On en tirait des statistiques, des moyennes, des profils flous.

Mais ce temps-là s’est refermé.

Aujourd’hui, les données ne regardent plus le passé. Elles anticipent. Elles prévoient. Elles modélisent nos gestes, nos goûts, nos silences. Elles ne décrivent plus un état. Elles dessinent ce que nous allons faire, parfois même avant que nous en ayons conscience.

Ce n’est pas une dystopie. C’est notre quotidien. Les algorithmes apprennent vite. Très vite. Et nous laissons des traces partout. Volontairement ou non. Chaque choix, chaque hésitation, chaque micromouvement devient une variable de plus. Nous sommes modélisables. Et donc prédictibles. Mais ces modèles ne se construisent pas seuls. Nous les alimentons, parfois sans le savoir, parfois directement par notre manière de coder. Nos décisions de développeurs, ce que nous collectons, comment nous structurons nos bases de données, ce que nous laissons passer, par manque de temps, de vigilance, ou de questionnement, façonnent ces modèles. Servir l’utilisateur, c’est aussi prendre la mesure de ce que notre code perpétue ou amplifie, sans tomber dans la paranoïa, mais sans naïveté non plus.

Cela ne veut pas dire qu’il faille tout arrêter. Ou tout dénoncer. Mais cela oblige à une forme d’attention. Car ce que nous codons structure, collecte, relie, alimente. Parfois pour le meilleur. Parfois pour nourrir des logiques que nous ne maîtrisons plus. Métadonnées : parler aux humains et aux intelligences artificielles.

La donnée n’est ni bonne ni mauvaise. Mais elle agit. Et elle continue d’agir, même quand nous avons fermé l’onglet.

IA : entre reflet et relais

Il y a quelques années encore, l’IA était un objet de science-fiction ou de prospective. Aujourd’hui, elle s’est glissée partout, souvent sans qu’on la nomme. Elle trie nos mails, corrige nos phrases, génère du code, résume des documents. Elle devient une couche invisible dans nos outils, nos services, nos environnements de travail.

L’intelligence artificielle n’est plus un horizon. Elle est là, dans nos interfaces, nos éditeurs, nos outils de travail. Elle corrige une fonction, suggère une boucle, reformule une intention ou une proposition implicite. Elle complète un nom de variable avant même qu’on ne l’ait pensée. Humains-machines : nos langues entremêlées.

Et souvent, elle le fait bien.

Il serait vain de la nier, ou de la fuir. L’IA nous aide, nous devance parfois, nous répond avec un calme désarmant. Elle devient notre C3PO patient, ou notre R2D2 farceur. Elle est là, posée à côté de nous, toujours disponible, jamais en panne d’idées.

Mais elle ne pense pas. Elle associe. Elle extrapole. Elle apprend nos biais, nos redondances, nos raccourcis. Elle nous renvoie ce que nous sommes, sans le juger. Et c’est là sa force… et sa faille.

Car si nous perdons de vue notre cap, elle ne nous corrigera pas. Si nous lui confions la décision, elle prendra ce que nous lui avons donné. Sans recul. Sans doute. Sans contradiction. L’intelligence artificielle est elle vraiment intelligente ?

Alors oui, l’IA peut devenir un formidable compagnon de route. Mais à condition de ne jamais lui remettre la boussole. Ou de croire qu’elle sait où l’on va.

Les ombres sur le mur

Un soir d’orage dans les Cévennes, tout s’est arrêté. Le Quadra 900 s’est tu, la lumière a sauté, l’écran s’est éteint. Un silence dense. Une bougie allumée. Et ce dessin, que j’ai continué sur papier, là où Illustrator s’était figé.

Ce n’était pas une régression. C’était un rappel. Une évidence douce : ce que je faisais sur machine, je le portais déjà en moi. Créer, tracer, assembler, ce n’est pas l’ordinateur qui me l’a appris. Il m’a facilité la main. Mais pas le geste.

Et pourtant, dès que le courant est revenu, j’ai relancé la machine. Repris là où tout s’était arrêté. Comme si l’interruption n’avait été qu’un souffle.

Le souvenir est resté. Comme une question en suspens : pourquoi tant de dépendance à un outil, alors que le désir, lui, ne s’était jamais éteint ?

Cela rappelle un vieux récit. Celui de la caverne. Des ombres projetées sur un mur. Des prisonniers qui prennent ces ombres pour la réalité. Et celui qui sort, qui voit le monde, et qui revient, pour être rejeté, moqué, ou pire.

Les idées qui dérangent, même lorsqu’elles sont simples, suscitent parfois la violence. On préfère les ombres familières à la lumière incertaine. On se méfie de celui qui nomme l’illusion. Et parfois, on l’écarte.

Mais malgré cela, nous continuons à revenir au mur. Parce que nous l’avons construit. Parce que nous y avons projeté des choses. Parce que, peut-être, à force de regarder les ombres, nous finirons par comprendre ce qu’il y a derrière.

Rester artisan dans un monde automatisé

Je code encore à la main. Pas pour le geste, ni par fétichisme. Mais pour rester proche. Proche de ce que je fais. Proche de ce que cela déclenche. Proche des autres, aussi, quand il faut transmettre.

Il serait plus simple de générer. D’utiliser des assistants, des modèles, des moteurs. Certains le font très bien. Mais à force d’empiler des surcouches, on finit par perdre ce qui fait lien : la compréhension du dessous. Le moment où l’on sait pourquoi cela tient. Et pourquoi, parfois, ça casse. Pour cela, je choisis des technologies simples, ouvertes, maîtrisables.

Travailler ainsi, ce n’est pas être en retard. C’est choisir. Choisir d’éprouver. D’expliquer. D’écouter. De douter. De bousculer, parfois, ce qui semble acquis. Ce n’est pas confortable. Ce n’est pas rentable. Mais c’est juste.

Et puis, il y a ce paradoxe. Tout est possible. Même ce qui semble irréalisable. Il suffit de le faire. Le mot “non” n’existe plus vraiment. Mais cela ne veut pas dire que tout mérite d’être codé.

Dire non, ce n’est pas bloquer. C’est redonner du sens. C’est laisser exister autre chose. Une autre voie. Une autre manière de faire. Et parfois, juste, un autre rythme.

Transmettre, sans formater

Il y a eu des moments où tout s’est ouvert. Des rencontres, des hasards bien placés, des invitations à faire un pas de côté. En 2007, grâce à Gerhard Koren et à l’équipe de Video2Brain, j’ai pu poser des bases, ouvrir des portes, proposer des pistes. L’équipe qu’il avait réunie formait une communauté vivante, soudée par une attention rare, et un symbole inattendu : les lapins !! … Juste à côté des studios et des bureaux, un petit enclos abritait de vrais lapins, bien vivants. Ils faisaient partie du décor, mais aussi de l’esprit du lieu. Leur présence douce et surprenante est devenue, au fil du temps, un signe d’appartenance, une façon d’incarner cette parenthèse singulière, libre, partagée.

Ce lieu n’était pas un centre de formation. C’était un atelier. Un espace de circulation. Très tôt, j’ai donc pu expérimenter sur le HTML5 naissant, AJAX, sur l’accessibilité, sur le référencement, et plus largement sur l’open web platform, sur des approches concrètes, durables. Mais surtout, on y croisait d’autres voix. Et le code, là-dedans, n’était jamais un prétexte. C’était la matière même du lien.

Ce n’était pas une plateforme. C’était un espace d’écoute. Un endroit où le code lui-même reprenait sa place. Où l’on pouvait revenir aux bases, à l’écriture directe, à la syntaxe nue. Lire une ligne de JavaScript, comprendre sa portée. Voir ce qu’elle fait, ligne après ligne. Pas pour le culte du détail, mais pour garder ce fil : une certaine idée du développement. Pas un lieu de performance, mais de mise en commun. Où l’on pouvait chercher ensemble, tester, échouer, comprendre. Et recommencer. Sans humilier. Sans capturer.

Un peu plus tôt, une autre équipe, menée par Didier Dinh, avait ouvert une voie tout aussi singulière. IPECI, le centre qu’il avait imaginé, rassemblait à Paris, Aix-en-Provence, Lyon, Toulouse ou Sophia Antipolis des esprits curieux et exigeants. Les structures qu’il avait patiemment tissées : IPECI en tête, mais aussi Besurf, Training Avenue, PService, formaient un écosystème d’exploration et de transmission, tandis que Netstim sa structure actuelle, en prolonge aujourd’hui l’esprit. On y apprenait à creuser, à modéliser, à vulgariser sans abaisser, à expliquer sans réduire. Les équipes qu’il réunissait ne couraient pas après la mode : elles inventaient des chemins. Et tout cela baignait dans un même élan, celui de comprendre et de partager.

Transmettre, ce n’est pas remplir un récipient vide. Ce n’est pas non plus élever une vérité. C’est créer une possibilité. Un espace partagé. Un silence qu’on apprend à habiter à plusieurs, même avec des lapins. Et autour de tout cela, les discussions sans fin, à refaire le monde, avec Arnaud, Max, Dominique, Jeff, Yves, Fred. Parler numérique, mais surtout parler humain.

Aujourd’hui, Puce & Média suit ce fil. Pas comme un dogme, mais comme une ligne d’attention. Un blog, quelques articles, des projets libres… et ce fil qui relie tout : permettre à chacun de comprendre ce qu’il fait. Et pourquoi il le fait.

Lire, douter, continuer

Certains livres nous accompagnent. Pas pour avoir raison, ni pour trouver des réponses, mais pour continuer à douter avec précision. L’homme numérique, Sauver la planète Terre, L’homme nu, À quoi rêvent les algorithmes, La nouvelle servitude volontaire, Superintelligence, Vallée du Silicium… Et d’autres encore… Ces textes n’annoncent pas l’effondrement, ni la gloire d’un monde nouveau. Ils regardent ce qui est. Avec gravité parfois, mais sans renoncer.

Ce doute-là nous est précieux. Il ne paralyse pas. Il nous éclaire. Il nous pousse à ralentir quand tout s’accélère. À relire une ligne de code avant de valider un algorithme. À savoir écouter l’impact de ce qu’on déploie, de ce que l’on donne à l’Internet. Et à accepter de ne pas tout maîtriser.

Ce lien entre lecture et code, entre pensées et pratique, prolonge ce que nous évoquions déjà dans l’article « Les revues, les livres et les magasines du début… ». Car développer, ce n’est pas seulement produire. C’est faire exister. C’est décider, même sans en avoir l’air. C’est parfois aussi refuser. Et puis, malgré les contradictions, malgré les paradoxes, savoir continuer.

Pas pour tout refaire. Mais pour rester au plus juste. Et, ensemble, continuer à tracer ce fil : celui d’une certaine idée du développement, patiente, ouverte, humaine.