Datant de 2009-2010, ce vario du fabricant Suisse Flytec reste un instrument fiable et robuste même après une quinzaine d’années.

Seul bémol, la puce qu’il intègre, notamment pour le chargement des vols et la communication avec un PC sont dépassés et peuvent poser problème. Il s’agit du Prolific PL2303 dont le pilote n’est plus supporté sous Windows 11. Un message d’erreur est même affiché avec les dernières versions du pilote/windows 11: « PL2303HXA Phased out since 2012. Please Contact your supplier« .

Il est possible, pour ~45 CHF de l’envoyer à Naviter (actuel propriétaire de la marque) pour upgrade du chip. Cependant il existe une solution encore plus rapide qui permet de faire reconnaître correctement le vario sous Windows 11.

La solution consiste à installer le pilote de 2008 (3.3.2.105). Pour le sélectionner, aller sur le périphérique et choisir: Mise à jour du pilote-> Recherche des pilotes sur votre ordinateur -> Choisir parmi une liste de pilotes disponibles sur mon ordinateur.

Depuis la dernière version de Windows 11, il semble impossible de choisir un pilote différent sur l’ordinateur (lié au message: « PL2303HXA PHASED OUT… ». Pour régler le problème, il faut choisir un port COM différent (chez moi, le passage du COM4 à COM6 a permis de régler le problème).

Le pilote 3.3.2.105 est disponible ici:

Il y a peu, j’ai été forcé de mettre à jour mon site basé sur une version obsolète d’un Framework, Twig/Symfony 3. En débutant l’implémentation avec CodeIgniter, j’ai vite compris que le portage des templates allait être compliqué. Je me suis donc orienté vers quelque chose de plus dynamique et moderne : un frontend en React avec un backend allégé par CodeIgniter. Le hic ? Je n’avais pratiquement aucune expérience en React. Pourtant, en quelques heures et grâce à une poignée de prompts à Grok 3, l’IA de xAI, j’ai réussi cette refonte. Voici comment ça s’est passé.

Une refonte en quelques étapes

J’ai d’abord repensé l’organisation de mon projet. Fini le mélange frontend-backend : j’ai créé deux espaces distincts, un pour le backend et un pour le frontend. Le challenge était de configurer mon serveur local pour que les requêtes API et les pages React aillent là où il faut. J’ai demandé conseil à Grok 3, et en une réponse, il m’a orienté vers une solution simple pour gérer ces redirections, sans que j’aie à me perdre dans des détails techniques.

Pour le backend, migrer de Symfony à CodeIgniter a été assez naturel. J’ai simplifié mes anciennes routes en endpoints légers, et Grok m’a aidé à m’assurer que tout restait cohérent et prêt à alimenter mon futur frontend.

Le frontend React, un défi relevé avec Grok

C’est là que les choses auraient pu se compliquer. Avec presque zéro expérience en React, je partais de loin. Mais Grok 3 a permis de relever le défi. Je lui ai demandé comment démarrer un projet React de zéro et comment en faire une version statique pour mon site. Ses réponses étaient claires, étape par étape, comme un guide patient qui ne me laissait jamais dans le flou. En un rien de temps, j’avais un frontend fonctionnel. Quand j’ai buté sur une erreur où mes données ne s’affichaient pas, Grok a tout de suite compris et m’a donné une astuce simple pour connecter React à mon backend.
Grok a même réussi là où les autres LLM (GPT 4o, Claude 3.5) avaient échoués: calculer le rendu, en React, de mon menu hiérarchique venant d’un json retourné par API. A prompt égal, c’est le seul à avoir réussi.

Quelques ajustements et un résultat bluffant

Tout n’a pas marché du premier coup. A plusieurs reprises j’ai confronté les résultats de Github Copilot, une recherche Google classique et Grok, Grok donne en général la meilleure des réponses avec le moins d’informations. C’est assez bluffant sachant que Github Copilot est totalement intégré à l’IDE contrairement à Grok qui n’a qu’un minimum d’information.

Une transformation éclair malgré mon inexpérience

En quelques heures et une poignée d’échanges avec Grok 3, j’ai métamorphosé mon vieux site Twig/Symfony en une application moderne React + CodeIgniter. Le frontend, presque entièrement conçu avec l’aide de Grok malgré mon manque d’expérience en React, est fluide et réactif. Le backend, lui, reste léger et efficace.

Si vous envisagez de moderniser votre site, même sans être un pro de React ou d’un autre outil, je ne peux que vous encourager à tester Grok 3. Attention toutefois à ce que vous lui transmettez comme information, Grok n’est pas connu pour protéger vos données, exit donc les mots de passe, données privées, etc.

Le site est disponible ici: https://ludovicfavre.ch/

En voulant tester quelques bouts de code utilisant Tensorflow, j’ai constaté que mon PC datait un peu: il n’a pas de support CPU supportant les instructions AVX.

Une version « raspberry-pi » existe depuis 2018 mais elle est loin de permettre de travailler efficacement. L’exemple classic sur le dataset MNIST prend en effet un temps assez conséquent à s’exécuter:

import tensorflow as tf
mnist = tf.keras.datasets.mnist

(x_train, y_train),(x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = tf.keras.models.Sequential([
  tf.keras.layers.Flatten(),
  tf.keras.layers.Dense(512, activation=tf.nn.relu),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(10, activation=tf.nn.softmax)
])
model.compile(optimizer='adam',
              loss='sparse_categorical_crossentropy',
              metrics=['accuracy'])

model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test, y_test)

Le résultat avec le raspberry-pi:

pi@raspberrypi:~/tensorflow $ python3 mninst.py 
 Downloading data from ...
 11493376/11490434 [===] - 2s 0us/step
 Epoch 1/5
 60000/60000 [===] - 107s 2ms/step - loss: 0.2007 - acc: 0.9407
 Epoch 2/5
 60000/60000 [===] - 104s 2ms/step - loss: 0.0797 - acc: 0.9758
 Epoch 3/5
 60000/60000 [===] - 104s 2ms/step - loss: 0.0515 - acc: 0.9835

...

Soit près de 2ms par step.

Depuis une année, Google propose Colab : https://colab.research.google.com qui permet gratuitement un environnement Jupyter avec tensorflow pré-installé. Il y a même des GPU disposition.

CPU:

Epoch 1/5 
60000/60000 [===] - 17s 289us/sample - loss: 0.2223 - acc: 0.9342 
Epoch 2/5 
60000/60000 [===] - 17s 281us/sample - loss: 0.0969 - acc: 0.9706 
Epoch 3/5 
60000/60000 [===] - 17s 282us/sample - loss: 0.0696 - acc: 0.9783 
Epoch 4/5 
60000/60000 [===] - 17s 286us/sample - loss: 0.0532 - acc: 0.9836 
Epoch 5/5 
60000/60000 [===] - 18s 301us/sample - loss: 0.0442 - acc: 0.9856 
10000/10000 [===] - 1s 64us/sample - loss: 0.0715 - acc: 0.9805 
[0.07151023466372862, 0.9805]

GPU:

Epoch 1/5 
60000/60000 [===] - 8s 136us/sample - loss: 0.2170 - acc: 0.9358 
Epoch 2/5 
60000/60000 [===] - 8s 134us/sample - loss: 0.0954 - acc: 0.9718 
Epoch 3/5 
60000/60000 [===] - 8s 133us/sample - loss: 0.0690 - acc: 0.9781 
Epoch 4/5 
60000/60000 [===] - 8s 133us/sample - loss: 0.0530 - acc: 0.9830 
Epoch 5/5 
60000/60000 [===] - 8s 134us/sample - loss: 0.0442 - acc: 0.9853 
10000/10000 [===] - 1s 70us/sample - loss: 0.0609 - acc: 0.9807 
[0.06085205714175245, 0.9807]

La version CPU sur Colab est plus de 5x plus rapide que sur un raspberry-pi et la version GPU 10x plus rapide (pour l’exemple ci-dessus).

Il peut donc être intéressant de créer ses modèles sur Colab, à condition d’être conscient que Google y a probablement accès…