dimanche 11 janvier 2026





 Le Vibe Coding : Quand la passion du développeur retrouve l'Intelligence Artificielle


Ce premier article de blog de 2026 aborde un sujet qui me tient particulièrement à cœur, à l'intersection de mes quarante ans d'expérience dans le développement logiciel et de l'évolution fulgurante de la technologie : le Vibe coding.


Mon parcours de programmeur a débuté il y a plus de quarante ans, à l'âge de neuf ans. En tant qu'ingénieur chercheur aujourd'hui, je contemple ce chemin avec une certaine nostalgie. Comme beaucoup de ma génération, mes premières lignes de code furent écrites en Basic sur un Commodore 64, puis sur le mythique Amstrad CPC 6128. C'est d'ailleurs sur ce dernier que j'ai découvert la programmation en assembleur, un langage bas niveau qui m'a procuré ma première poussée d'adrénaline de développeur en permettant de comprendre le fonctionnement intime de la machine et d'en optimiser les performances.


L'évolution m'a ensuite naturellement conduit vers la plateforme PC, où j'ai pu approfondir mes connaissances. J'ai consacré de longues heures à maîtriser le C et le C++, des piliers de l'ingénierie logicielle, tout en explorant le Pascal et en continuant les optimisations critiques avec l'assembleur.


Aujourd'hui, après plus de quatre décennies à coder, nous vivons une période absolument exaltante. Le domaine de la programmation est en pleine mutation, principalement en raison de l'émergence et de l'ascension spectaculaire des grands modèles de langage (LLM). Leurs capacités progressent à un rythme que personne n'aurait pu anticiper il y a quelques années. Ces outils ne sont plus de simples assistants ; ils redéfinissent notre interaction avec le code et la logique.


C'est dans ce contexte que j'ai commencé à intégrer ces nouveaux outils dans mon flux de travail personnel, adoptant notamment VS Code pour mes projets. Cependant, une distinction importante s'impose : par stricte nécessité de sécurité et de confidentialité inhérente à mon rôle d'ingénieur chercheur, je n'utilise aucun de ces outils basés sur le cloud ou l'IA générative pour le code dans un contexte professionnel, afin de protéger la propriété intellectuelle et les données.


Le « Vibe coding » se situe précisément à cette intersection. Il ne s'agit pas seulement d'utiliser l'IA pour générer du code, mais de retrouver cette connexion intuitive et profonde avec la logique du programme que j'ai connue enfant. Loin de nous aliéner, les LLM nous libèrent des tâches répétitives pour nous permettre de nous concentrer sur la conception architecturale et la résolution créative de problèmes, les aspects les plus nobles et stimulants du développement. Le Vibe coding, c'est l'art de laisser l'IA gérer la syntaxe et les implémentations courantes, tout en gardant une maîtrise ferme sur le « sens » et la « finalité » du code, renouant ainsi avec le plaisir originel de la création algorithmique.


Néanmoins, il est crucial de souligner que le Vibe coding n'est pour l'instant qu'un outil d'amélioration, et non un remplacement du développeur. Il exige une maîtrise de l'architecture du code sur lequel on travaille et une capacité à lire et comprendre ce que l'IA produit.


Parallèlement à l'évolution des outils de développement, on assiste à l'émergence exponentielle de milliers de logiciels et d'applications développés par des individus n'ayant aucune formation formelle ou connaissance approfondie en développement logiciel, ni même en sécurité informatique. Bien que cette démocratisation de la création logicielle puisse initialement paraître comme un progrès positif et une ouverture vers l'innovation pour tous, elle soulève un risque fondamental majeur et critique concernant la sécurité des données, la confidentialité et l'intégrité des systèmes.


Ces "créateurs de logiciels", souvent appelés "citoyens développeurs" ou utilisant des techniques de "low-code" ou "no-code" (et bientôt le "vibe coding" par simple description textuelle), sont désormais capables de produire des outils visuellement très attractifs, ergonomiques, et d'un aspect professionnel trompeur. Cependant, derrière cette façade soignée, se cache une ignorance totale ou partielle des implications sécuritaires fondamentales de leurs créations. Ils n'intègrent pas les meilleures pratiques en matière de protection des données, de gestion des vulnérabilités, d'authentification robuste ou de chiffrement adéquat.


L'utilisation, même occasionnelle, de tels logiciels représente donc un risque important pour vos données personnelles et professionnelles, ainsi que pour votre vie privée. Sans audits de sécurité, sans connaissance des failles potentielles (comme les injections SQL, les cross-site scripting, ou le manque de validation des entrées), ces applications deviennent des portes ouvertes pour les acteurs malveillants, compromettant potentiellement informations bancaires, identités numériques, communications privées et bien plus encore.


Face à cette vague, la question de l'avenir pour les jeunes ingénieurs et développeurs formés se pose légitimement. Je ne sais pas encore comment les choses vont évoluer. Je pense qu’après une vague initiale d’enthousiasme démesuré, où tout un chacun pourrait croire qu’il suffit de dicter en quelques mots à une machine le logiciel complet qu’on souhaite obtenir, le mur de la réalité technique, et surtout le mur de la sécurité et de la fiabilité, va inéluctablement replacer les choses à leurs justes places.


Tout comme l’invention de l’imprimerie n’a pas rendu les écrivains obsolètes, mais a transformé leur diffusion, tout comme l’apparition de la machine à écrire, puis l'avènement des traitements de textes sophistiqués, n’ont pas remplacé la nécessité du talent littéraire et de la structure narrative, le "vibe coding" ou toute autre forme de développement assisté par IA ne remplacera pas les développeurs logiciels professionnels et les ingénieurs qualifiés. Au contraire, ces technologies les rendront tout simplement plus efficaces, en automatisant les tâches répétitives et en leur permettant de se concentrer sur l'architecture complexe, l'optimisation des performances, et surtout, la sécurité critique et l'innovation de haut niveau. Le rôle de l'ingénieur évoluera vers celui de l'architecte, du spécialiste en sécurité, et du garant de la qualité et de la robustesse des systèmes.


vendredi 8 mai 2015

Compiler GCC 5.1 sur Raspberry 2

Aujourd'hui j'ai profité du jour férié pour compiler GCC 5.1 sur mon Raspberry 2.

En soit, la procédure n'est pas compliquée, c'est la même que sur n'importe quel linux sauf que depuis quelques temps la compilation nécessite une quantité importante de mémoire. En fait, il faut bien plus que le giga de RAM dont dispose la machine et je n'ai vraiment pas envie de faire de la cross-compilation.

Comme d'habitude, Linux montre sa supériorité dès qu'on sort un peu des sentiers battus. Pour "augmenter" la quantité de mémoire disponible j'ai tout simplement utiliser le module ZRAM.

Mon environnement est la Rasperian, sur les autres distributions la procédure est très proche.

Pour commencer, on va crée un petit script qui va nous faciliter la vie pour la zram :

Copiez les lignes ci-dessous dans votre éditeur favori et sauvegardez le fichier sous le doux nom de "enable-zram"

--------------------------
#!/bin/bash
modprobe zram &&
echo $((350*1024*1024)) > /sys/block/zram0/disksize &&
mkswap /dev/zram0 &&
swapon -p 10 /dev/zram0 &&
exit 0
--------------------------

Ensuite :

chmod +x enable-zram
sudo ./enable-zram

Et voilà, vous disposez maintenant d'une zram 350 Mo.

Maintenant on va télécharger et préparer gcc 

wget http://mirror1.babylon.network/gcc/releases/gcc-5.1.0/gcc-5.1.0.tar.bz2

tar xjvf gcc-5.1.0.tar.bz2

cd gcc-5.1.0

On prépare les variables d'environnements qui vont bien

export LIBRARY_PATH=/usr/lib/$(gcc -print-multiarch)

export CPATH=/usr/include/$(gcc -print-multiarch)

et enfin, on passe à la configuration et à la compilation

./configure --prefix=/opt/gcc

make -j2

Remarquez que je compile sur deux coeurs au lieu de 4, nous n'avons tout simplement pas suffisamment de mémoire pour utiliser 4 processus de compilation en même temps, à un moment ou un autre nous risquons de manquer de mémoire.

Voilà, maintenant vous pouvez allez profiter de la journée dehors ou regarder le premier épisode de la trilogie du seigneur des anneaux car la compilation prend beaucoup de temps. Une fois de retour devant votre machine, il ne vous reste plus qu'un installer le compilateur fraîchement compilé :

sudo make install

Et gcc 5.1 sera installé dans /opt/gcc


lundi 4 mai 2015

Installer SDL2 sur Raspberry pi 2 sans XWindow

En ce moment mon nouveau jouet c'est le Raspberry PI 2.

Evidemment, la première chose juste après avoir installer Raspian dessus c'est d'essayer de dompter la bête avec des outils de poilus (le premier qui me parle de Python je lui coupe l'accès à mon blog).

Soyons claire, XWindow sens des dessous de bras sur un PI. C'est bien pour frimé 30 secondes (ouais, c'est un vrai ordinateur) mais pour les choses sérieuses c'est pas le pied.

Sur le PI il existe 3 options de base pour coder et afficher des zolies images :

  1.  OpenGL ES
  2.  OpenVG (je l'aime bien lui)
  3.  Framebuffer des familles.

Mais aucune de ces trois méthodes ne va nous offrir un accès facile aux autre fonctions dont nous pouvons avoir besoins (accès souris, clavier, tactile, ttf...etc).

C'est la que rentre en scène ce bon vieux SDL.

La bonne nouvelle c'est que SDL 2.0.3 est compatible avec le PI 2 à condition de respecter quelques règles de base.

  1. N'essayez pas de l'installer à avec apt-get
  2. Le compiler vous même.

Par chance l'option 2 est simple comme tout.

Assez de blabla, passons aux choses sérieuses.

Téléchargez SDL2 

wget https://www.libsdl.org/release/SDL2-2.0.3.tar.gz

Décompressez l'archive

tar xzvf SDL2-2.0.3.tar.gz

On se place dans le bon répertoire

cd SDL2-2.0.3/

et on passe les options magiques à configure

./configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl --prefix=/opt/sdl

En gros, on désactive tout et SDL va se rabattre automatiquement sur ce qui lui reste comme option. C'est à dire Opengl ES 2, c'est exactement ce qu'il nous faut pour bénéficier gratuitement de l’accélération matériel.

Il ne reste plus qu'a compiler tout ça

make -j4

et ensuite

sudo make install

Et voilà.

Dans le prochain épisode, on va compiler SDL_image et consort.


lundi 15 juillet 2013

Activer std::this_thread::sleep_for avec GCC

Je suis en train de m'amuser en ce moment avec C++11 (C++0x pour les intimes).
Il se trouve que la version 4.8.1 de GCC offre un support complet contrairement à VC2012 (VC11).

Tout se passait à merveille jusqu’à ce que j'essai d'utiliser std::this_thread::sleep_for et consort, le compilateur m'envoyant systématiquement une insulte me disant que la méthode n'existe pas...

Une petite recherche sur l'internet m'a permis de trouver la cause du problème, en fait cela vient d'un bug du script de configuration. Pour activer std::this_thread::sleep_for il suffit de passer :

--enable-libstdcxx-time=rt (sous Linux)

ou

--enable-libstdcxx-time (pas testé)

comme paramètre à configure.

Voici un petit exemple :

./configure --prefix=/opt/gcc CFLAGS='-O3'  --enable-libstdcxx-time=rt --enable-languages=c,c++

Ensuite, tout rentre dans l’ordre !

dimanche 31 mars 2013

Drivers Nvidia pour Opensuse 12.3

L'autre jour j'ai installé comme à mon habitude le driver Nvidia pour Linux sur une machine équipée d'une carte quadro.
L'installation se passe bien, l'installeur trouve bien les sources du kernel, exécute ses scripts pré et post install et je reboot. Je me dis tout va bien dans le meilleur des mondes et là c'est le drame. Le driver est bien installé mais pas d’accélération 3D...

En fait, c'est tout simplement un problème de droits sur les devices nvidia. Pour régler le problème il suffit de créer le fichier suivant


/etc/udev/rules.d/50-udev.rules avec ce qui suit :

----------------------

##################/etc/udev/rules.d/50-udev.rules############

KERNEL=="nvidia*", NAME="%k", GROUP="users" 

##################end of /etc/udev/rules.d/50-udev.rules#####


Rebooter et tout rentre dans l'ordre !


vendredi 14 janvier 2011

Android market

depuis quelques temps j'utilise l'Android Market non plus comme simple consommateur mais comme producteur. Aujourd'hui j'en suis à trois applications sur le Market et une quatrième est en cours de développement.

Je dois dire que je reconnais bien là la marque de Google, une interface sobre, claire et efficace. Le Market permet en effet de déployer rapidement une application et cette dernière apparait quasi instantanément sur les terminaux. Mais étrangement le Market souffre d'un problème majeur, il n'offre tout simplement aucun outils de suivie de l'utilisation des applications. C'est à peine si on sait combien de fois une application à été téléchargée.

La console d'administration est mise à jour une fois par jour... parfois.

Cela devient un vrai problème lors de la première publication d'une application. En tant que développeur on à évidement envie de savoir si notre dernier bébé se porte bien, si les utilisateurs l'apprécies, bref, si il plait et parfois pendant plusieurs jours... rien, pas de statistiques, rien.

J'ai beaucoup de mal a comprendre comment une entreprise capable d'offrir la recherche temps réel, la traduction temps réel et bien d'autre services à des millions d'utilisateurs à travers le monde est incapable d'incrémenter un simple compteur et l'afficher dans une console.

La vérité c'est que tout les développeurs se posent cette même question à la quelle Google n'a jamais daigné réponde...


Ceci n'est bien évidement rien d'autre que l'expression de la frustration du jour.


jeudi 7 octobre 2010

Les applications payantes

Hier j'ai vu l'application iCoyote était sortie pour Android. Je me précipite donc sur le market et la j'apprends que l'application est gratuite jusqu'à fin décembre. Je me dis chouette, ça va me laisser le temps de le tester à fond puis sans doute de prendre un abonnement si l'application est bien réalisé.


Comme c'était le soir et qu'après une harassante journée de travail je n'avais pas spécialement envie de sortir pour tester l'application, je me suis dis que meilleur moyens d'avoir rapidement un retour c'était de lire ce que les gens en disent sur les forums.


Je suis donc aller sur différents sites qui annoncent la sortie de l'application et j'ai été surpris de voir à quel point les utilisateurs peuvent être cassant envers une application à partir du moment où elle est payante et ce quelque soit le prix.


Les commentaires fusent de tout les cotés pour dire à quel point l'éditeur de l'application se moque du monde, qu'il prend les gens pour des « vaches a lait » alors que c'est les utilisateurs qui remontent les informations de trafic.


Ce que ces gens ne semble pas comprendre c'est que derrière iCoyote il y a des gens qui travaillent, des bureaux, une infrastructure technique, un S.A.V…etc


Sans cesse il y a une comparaison qui est faite avec des application qui font de près ou de loin la même chose sauf que tout le monde s'accorde sur le fait que ces applications n'ont pas toujours la masse critique d'utilisateurs nécessaire pour rendre le service utile.


Et si jamais une de ces applications commence à marcher vraiment, dans le sens où il a beaucoup d'utilisateurs qui va payer l'infrastructure technique nécessaire pour prendre en compte des milliers de remonté d'information, de compilation et de redistribution vers les utilisateurs ? Il y a une différence entre une application qui à quelques centaines d'utilisateur sans garantie de service et une application utilisé quotidiennement par plusieurs milliers d'utilisateurs avec des serveurs correctement dimensionnés, redondants et surveillé 24h/24.


Je me demande au finale si ces gens la travaillent ou bien si ils acceptent de travailler gratuitement, parce que c'est bien ce qu'ils demandent aux développeurs.