IoT status, as I see it

For the last 5 years, I have worked in a small company that was creating a software to manage data coming from various sources, and that includes IoT devices (but not only).

This is a weird ecosystem.

One would think that this was a booming one, since it was all around the IT news in the past 10 years (a bit less now), but it was mostly hype.

So what is it about, from my little corner of this ecosystem?

This post is certainly not going to provide an in depth analysis of the ecosystem, it's just a feedback of 5 years to tangent this area...

IoT, as I see it used

It was mostly about installing energy sensor (current sensors, temperature sensors, etc). Mostly for the industries, because they were under heavy stress to lower their energy consumption since 2022.

The idea is that if you don't measure, you can't tell where you are wasting resources. So a sensor sounds like a good idea. Except that it's expensive. A current sensor is typically costing a few tens of $, a bit more if you want to have a network able one.

If you want to control a factory, we are talking of tens of sensors, that must be installed, checked regularly, controlled, updated, and supervised. 

Installing such a device is not that complex (it takes a couple of minutes), but you have to take care of many aspects:

• Is it easy to access once installed, because you may want to change its battery

• Is it protected against chocks, water, etc

• Has it a decent network access

The other kind of sensors are pretty intrusive. Typically, if you want to measure water consumption, you need a plumber to install it. Costly...

Or you can install such devices on your counter, but it's a global measure, when you want to know how much water is used by a specific machine, or room.

Bottom line, the cost of a single sensor is really minor compared to the cost of managing it in the long run, questioning the ROI.

Here be dragons

So let's say you have decided to monitor your factory. Good.

I hope you have cautiously selected you sensor providers. Because it's a tough ecosystem. What if it goes bankrupt? Have you a stock of spare devices, just in case?

I see it happening: a superb installation, top notch sensors. Except that when the company went down, those fragile sensors that have a 3 years life expectancy where impossible to replace. So the company had to replace *all* if the sensors, paying the price for that, plus the installation, software modification, etc. Pretty much spending the same money than for the initial setup.

What about security? In another use case, the user wanted to leverage pretty old webcams they payed good money for. For sure, they were still working. But the only supported secured protocol was TLS 1.0, which is now unsupported by all the existing browsers. Typically, embedding the video into today's browser is just difficult (proxy required with a TLS downgrade in the middle, etc...)

What about security, again? So you have deployed tens of sensors, and now you realize that non secured transmission of data is a no go. Do you have a way to install certificates, and to manage them properly (expiration, renewal, etc)? Of course access through a strong password is a must. But what about OTP? Does your device support it? Can it be upgraded remotely? Do you have a centralized system to manage all those updates for all your sensors without having to send someone on site to do it one sensor after the other? Not to mention software updates...

Generally speaking, people tend to think that sensors measuring non critical information like electricity consumption does not require a high level of security. Maybe... Until your factory is destroyed like what happened in Iran.

Also keep in mind that many sensors are used in a non secure environment, using antiquated protocols (just giving an example), managed by brittle pieces of software.

Measure is only one part of the equation!

Ok, so you have measures coming in. Now, what are you going to do with it?

If you don't have a software to leverage the flow of data, well, it's useless. And this is where it's start to be complicated.

Your software platform should be able to build decent dashboards, with alarm. It should also be able to manage the sensors status (battery, software updates, sensors security). More important, adding new sensors should be easy. Last, not least, you should be able to navigate through all the data in an  efficient way (like, comparing data across the years).

This is where things get *very* complicated. You'll spend many times more on setting up such a platform than what you have spent on devices.

First because you have to define precisely what you want to obtain, which is hard. Second because your requirements will change across time, so you'll have to update your dashboards. Third, your platform should be versatile enough to embed new sensors, new measures, etc. Last, not least, this platform should work for years!

All in all, this is complicated and costly.

What about performances?

So you have picked your platform, fine. It works great, just becoming slower and slower...

Why? Because you have added many sensors. Because you have increased the measure frequency. Because the software is not well written...

Let's say you have 1000 sensors, sending a measure every 5 minutes, 24x7. That means:

• 200 measures per minute, a bit more than 3 per second. So far, so good.

• 12 000 measures per hour

• 288 000 measures per day

• Almost 10M per months

• 100M per year

Now we are talking. If your platform is not properly tuned, when you request a sum up  for the year, you bring back millions of data from your database. And generally speaking, your browser is the part in charge of showing the beautiful graph with those millions of dots... Not to mention your database that will be pounded during such a request, and the gigabyte of data crossing the network...

Did I mention the terabytes needed to store years of data?  In the previous list, storing 100M entries requires tens of gigabytes (assuming each measure is encapsulated into a 100 bytes piece of data). Sadly, most of the time those pieces of data are stored as JSON (it's so easy to read and process!!!), increasing the original payload size by a factor 2, 3 or more. Add to that you want indexes to speed up direct access. Many indexes...

One sad example: a user who has designed a dashboard that exposes monthly graphs. The sent requests are fetching all the data from many sensors from the 1st day to the current day. Strange enough, the dashboard and the underlying servers are pretty responsive on the very beginning of the month. Not so much when it comes to doing the same request on the 30th...

The problem is that those dashboards are expecting to be easy to develop: "Even a manager can do it!". Short answer: NO.

Last, not least, and I didn't mentioned it, between your data and your dashboards, there is a piece of software intended to manage the workflow: how to process incoming data, convert them properly, doing something useful out of it (like sending alarms, etc). This is the heart of your system, and you generally don't see it... And this is the most complex part!

What about failures?

Ok, you have a working system. Your sensors are setup, their battery are full, they send you back the data without losing the network connection, the workflow and your dashboard have been carefully designed.

Your 1000 sensors sending data every 5 minutes are easily processed on the flow. All in all, 3 messages per second is not that much!

Except that for some unexpected reason you haven't received any data for a full week-end. Hopefully, all the sensors aren't sending the data directly to your system, there is a gateway in the middle that has a beautiful feature: it can gather the data and keep them available until you connect your middle ware. 

That means during this week-end, 600K messages have been stored in the gateway, and your admin was able to restore the machine which was running your middle ware on Monday morning (somebody has made a mistake and changed a rule in the firewall, damnit!)

And suddenly your middleware is flooded with half a million messages! Not counting the 200 messages per minutes that are also coming. It will take tens of minutes to process all those data, and it will potentially stress the server to a point they might crash. And the manager who have an urgent need to access the dashboard, because he needs to print a beautiful graph for the 10AM presentation he/she gives to the company board... (yeah, I have seen that. Many times!).

Here, I'm talking about non critical measures, but there are many use cases where we are talking about critical data (think about a factory, or a construction site requiring a real time monitoring).

I have not yet mentioned backups, failover, up time, etc.

Miscellanea

I have faced some quite weird issues during those last 5 years... One of the 'funniest' one was when we installed some sensors into a building. They were not connected with wire, but through a LORA network.

(LoRaWan is a dying radio transmission protocol. It was quite everywhere a few years ago, because it's cheap. Anyway, that's not the issue.)

So we had gateways in the building, a square 4 storey one, with a inner patio. The idea was to install a gateway per floor, in one corner.

Except that it never worked properly. We were losing data for half of the sensors. So we had to send someone with a radio monitoring device to understand why we were losing data...

Bottom line, the windows on the patio were using armored glass with a thin layer of metal to protect against the sun shine... Faraday all over!

Another 'funny' story was the insulated site we were installing, with a 128Kb network access. Barely enough to access it on a text monitor, clearly insufficient to expose 10Mb web pages produced by the dashboards...

Conclusion

I have just scrapped the top of the various issues you will face when conducting such projects. Not to mention that when it comes to energy monitoring, you also have some legal and financial constraints (just because there is a CO2 market, so every ton of CO2 you spare has a value, but you have to *prove* you have really spared it...)

This is quite a rich ecosystem, not so mature, still with a LOT to do.

 OSS maintenance, what does it means?

I'm  maintaining (and developing!) a few Apache projects:

• Apache MINA: A Java NIO framework
  
• Apache LDAP API : A LDAP Java API
  
• Apache Directory Server: A LDAP server in Java
  
• Apache Directory Studio : A LDAP browser based on Eclipse
  
• Apache Mavibot : A MVCC database in Java

Those are quite old  projects (Apache Directory Server was created in 2004, and incubated in 2005). 20 years old actually!

What does it means in term of effort?

The language

All those projects are written in Java, and it was started using Java 4 (actually, the reason Alex Karasulu started to develop the LDAP server back in 2003 is that it supported NIO, which allowed an unlimited number of connections, something that was quite a limitation with Java 3 blocking IO when it comes to manage thousands of concurrent connections.

We are now supporting Java 8 to 21, which means Java 4, 5, 6 and 7 are not anymore supported.

The question is: why do we still support Java 8? Back in 2023, around 30% of Java users were running their applications based on this version. This sounds insane, but you have to keep in mind that when it works, don't even try to fix it. Also the recent Java release policy has make it so that releases are way more frequent, otherwise we would be around version 10 or 11 today.

Also there are not so many new features since Java 8 that worth the effort. I mean Java 8 already has lambda, and the added features aren't that critical, up to Java 21, which introduced Virtual Threads.

 Last, not least, Oracle has changed its policy so that it was not anymore free to use Java in production (they reverted back since then).

So we are good to go with older version of the language.

Are we?

Dependencies

When it comes with dependencies, the language version matters. For instance, if you depend on SpringFramework, then suddenly you can't migrate to the latest maintained version, 6.X. It requires java 17 :/

So now we are at a cross road, where some dependencies are evolving faster than we can cope with. What can we do?

First of all, check if the dependency is really that necessary. Regarding SpringFramework, it is used in two MINA modules, one containing some examples, the other one is based on a defunct container project (Apache Geronimo Xbean). 

The question is to keep this dependency (and being incapable of updating the dependency) or removing it from the code base (and breaking the API contract).

The thing is that some very old versions of what we maintain are still being used as of 2024. Here is a snapshot of the MINA download statistics for last month. 5% are for a 12 years old version (2.0.7, released in November, 17, 2012!).

Mina download statistics

 

So we are kind of stuck, and expecting users to upgrade to a more recent version is putting a lot of burden on them.

The other problem with dependencies is that even if we don't include them in the release packages, we may use some for tests. I'm thinking about mock libraries, for instance. Making a choice a decade ago stuck you for a very long time, unless you are willing to migrate potentially thousands of tests.

For instance, I have spent 3 months migrating all the MINA and Directory projects to Junit 5 last year. Not the best usage of my precious time :/

The very same with Log 4J which is stuck in an old version (1.X). Migrating to Log4J 2.X would require a massive effort.

What about projects versions?

We maintain more than one version of each project:

• Apache MINA is supported in three versions, 2.0.X, 2.1.X and 2.2.X
• Apache LDAP API is supported in two versions, 1.0.X and 2.1.X
  

 This requires a lot of effort, with some backportings, releases, documentation, including migration howtos.

Is it necessary?

Yes, and no. yes, because when you are committed with a given version, migrating can really be a burden. The API change, the updated dependencies, all are going into your path.

So as a maintainer, you are going to make a choice at some point: when to deprecate a version and tell the users they *must* migrate. 

OTOH, a feature addition or an API change are not that frequent in decades old projects, so switching to a new version is not that frequent either.

The development environment

Projects are getting older, developers are leaving, and you are still around and in charge. This is a volunteer organization, nobody forces you but still: you have to deal with all those external evolution.

For instance, your projects were using SVN, and it's migrating to Git. Load of effort on you side !

Your favorite IDE is also evolving, and some developers are using an IDE you don't like or you do'nt want to spend days to learn. That's also something to deal with.

What about the build tools? We migrated from Maven 1 (yuk) to Maven 2 (slightly less worse) to Maven 3. Some were pushing to switch to Gradle. Still, you have to learn how to use each of those versions, and each of those tools.

GitHub was a big revolution, and nowadays almost all the tickets are submitted through a PR, while we are still using Jira. That means we have to regularly check both environment, and move PR from GitHub to Jira for a better followup: more work!

Did I mention the web site? In the course of 20 years, we moved from a static web site, to a generated one based on Confluence, then to the (now defunct) ASF CMS system, and lastly to Hugo. Again lots of work!

Is it worth it?

Yes! Because thousands of developers around the world are using those projects. Because it's rewarding. Fixing bugs is always an immediate satisfaction.

Bottom line, maintainers are dedicated persons who like keeping a clean place. And I'm proud of being one of them!

 

L'université Française, dans toute sa splendeur...

Ok, c'est pour bosser 6 h par semaine, donc au final, c'est bien payé ! (mieux vaut en rire...)

Le nouveau ministre de l'enseignement supérieur, Thierry Mendions, a du pain sur la planche. Heureusement qu'on a un gouvernement de gauche !

Allez, voici le mail : 

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

*OFFRE D'EMPLOI POUR UN POSTE D'ENSEIGNANT-E CONTRACTUEL**-LE*

*Intitulé :** Anglais 11ème section*

Nombre d’heures : 192  heures équivalent TD (réparties sur toute l’année
universitaire)
Rémunération mensuelle brute sur 12 mois: 1152 euros (sans doctorat) ou
1504 euros (avec doctorat)
Affectation : Université de Cergy-Pontoise, UFR LEI, département d'Anglais
LLCE - RER Cergy-Préfecture

Le département d'anglais de l'Université de Cergy-Pontoise recrute pour
l'année 2015-2016 un-e enseignant-e contractuel-le (contrat mi-temps sur
support vacant du 2nd degré). Les candidats doivent être titulaires (au
minimum) d'un diplôme d'études anglophones de niveau Bac + 5. Les candidats
certifiés ou agrégés devront demander à être détachés de l'enseignement
secondaire.

Les besoins d'enseignement sont principalement dans les spécialités
suivantes:
- civilisation américaine
- traduction (thème et version)
- histoire de l'art
- préparation à l'insertion professionnelle

Les pièces demandées sont les suivantes:
•    une lettre de motivation
•    un curriculum vitae
•    une copie des diplômes universitaires
•    la copie d'une pièce d'identité

Les dossiers sont à adresser par email exclusivement aux adresses
suivantes: xxxxxx@u-cergy.fr,  yyyyyy@u-cergy.fr et
zzzzzz@u-cergy.fr
-----------------------------------------------------------------------------


Pathétique...

Projet de loi relatif au Renseignement

Dans 12 jours, le gouvernement Français, profitant de l'émotion suscité par l'assasinat lâche de journalistes, va mettre aux votes une loi scélérate.

Il est de notre devoir de faire savoir à nos députés que nous n'acceptons pas de devenir citoyens d'un état (potentiellement) totalitaire. 

Le texte de loi est disponible ici.

Vous pouvez consulter ce site pour vous informer de la façon de contacter votre député.

Voici le mail que j'ai envoyé à Mr Goasguen, député du 14ème arrondissement :


Monsieur le Député,
vous avez l'honneur de représenter le 14ème arrondissement de la ville de Paris, dans lequel je suis domicilié. A ce titre, vous me représentez également.


Je me permets donc de vous interpeller sur le projet de loi qui est amené à être voté dans deux semaines. Celui-ci comporte des risques inacceptables sur les libertés fondamentales, tels que spécifiés dans l'article 811-1.

L'article 821-1 précise que l'autorisation de mise en oeuvre du recueillement d'informations relève de sept personnes :
- le premier ministre
- et 6 personnes qui ont délégation du premier ministre

L'exercice de cette commission de contrôle, dont la composition est hautement politique, violerait le principe de séparation des pouvoirs, principe fondateur de notre république, et préambule à notre constitution. Il n'est pas envisageable que cette entité distincte du pouvoir judiciaire puisse remplir un rôle qui est du ressort du judiciaire.

Voter cette loi serait donner raison à toute forme de terrorisme, rangeant la France dans le groupe des nations disposant d'outils de surveillance dignes de systèmes totalitaires. Non, l'assassinat ignoble de journalistes ne saurait justifier la mise en place d'un tel système, que ces journalistes auraient bien évidement rejeté avec la plus grande fermeté.

Je vous demande de faire ce qui est en votre pouvoir pour faire rejeter cette loi liberticide. Il ne s'agit pas ici d'une position politique, mais d'une position de principe. Votre devoir est de défendre les principes fondamentaux qui font la grandeur de notre république, au delà de tout attachement partisan.

Je vous remercie par avance,

Emmanuel Lécharny
7 Square de Chatillon,
Paris 14

I have a dream...

Ce dimanche, il fait un peu gris, la choucroute mijote dans le fait-tout... Il me reste une petite demi-heure avant de passer à table, la famille est en route, j'ai le temps de me laisser aller à une petite rêverie informatique.

Mon camarade Antonio Goncalves, un des organisateurs de Devoxx.fr (pub plug) se plaint de l'incapacité de l'administration à mettre en place une informatique qui fonctionne.

Qu'en dire ? Qu'un programme comme Louvois, lancé en 1996, abandonné en 2013 après avoir foutu à la poubelle dépensé 470 M€ puisse avoir été un tel echec est la preuve que l'état est incapable de gérer son informatique. Et des faillites équivalentes, il y en a : project Chorus (500M€), Dossier Personnel Médicalisé (500M€ pour 400 000 patients...), l'Opérateur National de Paye (750M€).

J'ai également en tête l'informatisation de la DGI, où l'état avait missionné deux énormes sociétés française (sans doute pour les sauver en ces années de bulle internet...), qui facturaient entre 1000 et 2000€ la journée, et qui avaient bien sûr des sous-traîtants, qui eux même prenaient des sous-traîtants... Ceux qui ont effectués leur déclaration par internet la première année se rappellent bien de la totale incapacité du système à ternir la charge à l'époque bien faible. Le project COPERNIC a coûté 1.5G€ (cf le rapport du sénat).

Bref, on se dit qu'il y a des marges de progression. Mais dans quel cadre technique, juridique et surtout organisationel ?

C'est là que je me mets à rêver. Je lisais il y a quelques mois cet article édifiant, où était décrit l'opération commando qui 'sauva' Obamacare. Je me dis qu'il devrait être possible de faire la même chose en France.

Nous avons un vivier d'Open Sourceurs, assez large en plus. Dans des domaines variés, qui couvriraient largement le spectre de l'informatique mise en oeuvre par l'état. Ce sont nos impôts qui financent ces échecs, et ce sont également nos impôts qui (sur)payent les systèmes qui finissent par fonctionner (mal). Ne serait-il pas possible de réunir assez de compétences pour remettre en état un de ces systèmes, à coût nul pour l'état, pour un résultat fonctionnel, mais également moins onéreux en fonctionnement ?

L'idée - le rêve - serait de mettre à disposition d'un des projets en souffrance une équipe pluridisciplinaire compétente, disponible, et cela gratuitement.

La gestion de projet serait totalement collaborative, sans la contrainte temporelle et budgétaire si mortifère dans un cadre contractuel classique : à savoir que l'on se focaliserait sur les fonctionalités, les performances, l'évolutivité et les tests, au lieu de se limiter à livrer dans les temps, à l'aide de stagiaires si besoin (vécu...).

On s'épargnerait la recherche du profit - ou plus souvent la limitation des pertes dans l'espoir de se refaire grâce à de substantiels avenants que le client se voit bien obligé de signer... -, au profit de la satisfaction du 'client' - c'est à dire, le citoyen -.

Il serait possible de dire non, mais également de remettre en cause les choix initiaux, puisque l'objectif est d'aboutir à un système fonctionnel, sans craindre un clash avec le client. La relation avec ce dernier serait de même bien plus confortable, car on éviterait d'accumuler les "preuves" de malfaçons et de non respect des délais et des fonctionalités, puisqu'aucune pénalité de retard ne serait en jeu.

Bien sûr, on ne peut imaginer disposer de quelque dizaines d'informaticiens compétents pendant une période de six mois ou un an sans les payer, alors - second rêve - j'imagine un système de sponsoring, ou de crowdfunding permettant de financer cet effort.

Et pourquoi pas ?

A condition que les lobbies, puissant, des SSII, laisse faire, bien sûr : la fonction publique est une source majeure de revenu récurrents pour ces sociétés. Et que le droit administratif ne vienne pas se mettre au travers d'une telle démarche : comment éviter de passer au travers d'un appel d'offre public?

Dernier point : pourquoi ne pas profiter de ce cadre pour former ? Au lieu d'envoyer des stagiaires achever des projets comme on achève les chevaux, on les enverrait se faire former dans un cadre plus souple, et surtout par des personnes compétentes, et disponibles. Ce serait aussi l'intérêt des SSII de 'sponsoriser' un projet donné, par délégation de personnel : après tout, il n'est pas si fréquent de pouvoir se confronter à des problématiques complexes dans un cadre réel, sans les contraintes habituelles. Un lieu magique où la recherche de solution serait possible, un projet Manhattan à la Française en quelque sorte...

Et pour 50 personnes, payées - soyons généreux - 100 000 € par an, plus 2 M€ de frais de fonctionnement (ordinateurs, locaux, télécom, frais divers), soit 7M€ par an, allez, 10M€ en intégrant les charges sociales, je serai surpris qu'on n'arrive pas à produire quelque chose qui fonctionne, à comparer aux coûts délirants des projets nommés ci-avant...

On pourrait même imaginer les faire tourner dans un cloud Français ! (Ok, là,  je parle d'un vrai cloud, pas d'une sorte de FranceStein du cloud financé par vos impôt, hein !)

Ok, je rêve... Mais après tout ?

Et vous, il vous arrive de rêver aussi ?

Allez, la choucroute m'attend...

About Perfection and OSS

From time to time I feel like we all have our own Moby Dick, and when it comes to OSS, it's name is 'perfection'.

Those shiny moments of pure joy, this warm feeling that surround you, when you can say 'mission accomplished' are rare and vanishing periods when you work on a never ending project. Its more or less when you get a big bug fixed, or when you read some enthusiast review on the project you are working on.

Fixing a bug is probably the best way to get this reward, as you know that you have made some progress.

It's forever shadowed by the constant pain of knowing that there are other bugs, and that in order to get a release done, you had to make some choices, leaving problems behind.

Is it a sad story about being a developer? No. It's not sad. It's tough, it's long, it's an endless job. Would I prefer doing something else? Certainly not ! At least, I know what I'm chasing, and even if I rarely foresee this fading perfection, sometime, I can almost touch it. Not something you can experience when you work in a company, as you don't have the opportunity to polish the project as much as you want, due to time constraints.

Last, not least, you are not alone. When you think that you are turning in circles, you know that the community you are part of will help you. Use it : they have the clues you don't have.

An Arabic proverb says "It's not that the way is painful, it's just that the pain is the way". So you better deal with it.

Free ADSL, où comment ne pas avoir d'ADSL pendant plus d'un mois...

Ne plus avoir d'électricité pendant 2 jours, sauf en cas de tempête, est juste inconcevable en France. Pour une connexion ADSL, vous pouvez rester coupé pendant plus d'un mois sans que cela ne semble soucier votre provider, en l'occurence Free.

On ne parle pas d'un village au fond d'une vallée reculée du haut morvan, là. C'est à Puteaux, dans la proche banlieue parisienne.

Tout commence par une intervention sur une ligne par l'opérateur historique, le 24 septembre 2014. Résultat, une ligne ADSL dont le débit chute brutalement à 500Kbits (54db) au lieu de 10Mbits (42db). Typique d'une ligne abimée, ou d'un signal affaibli par une interaction magnétique ou un cable de mauvaise qualité.

Et là, la boucle infernale commence : ouverture de ticket d'incident chez Free, une semaine de délai avant vérification des équipements (et oui, c'est toujours chez vous que le problème se situe, par défaut !), puis suite à la vérification du bon fonctionnement de l'équipement, on bascule chez l'opérateur historique (entendez FT), par le biais de ce qui s'appelle un GAMOT. C'est encore une semaine d'attente...

Suite à quoi, généralement, FT ne détecte bien sûr aucun problème, et ferme le GAMOT. Vous venez de perdre 2 semaines...

Voilà, vous devez réouvrir un ticket chez FREE, qui va cette fois devoir aller plus loin que de constater que votre matériel fonctionne bien et rouvrir un second GAMOT. Puisque qu'aucun des deux opérateurs ne reconnaît un problème chez lui, c'est qu'il doit y avoir un problème entre les deux...

(Entre temps, votre voisin, qui est abonné chez FT, lui, a été rétabli dans les 2 jours...)

Que se passe-t-il lors de cette "procédure d'expertise" ? Et bien les deux sociétés font intervenir deux techniciens pour tester la connection de bout en bout. Généralement, ils découvrent à cette occasion un mauvais branchement, et le rétablissement a lieu - si tout va bien ! -.

En pratique, il faut compter un bon mois, parfois moins, parfois plus.

Et ce n'est pas normal.

Dans le meilleur des cas, on parlera d'incompétence, mais reste à savoir chez qui. En pratique, la question de la procédure mise en place chez les deux sociétés (et on peut imaginer qu'il en est de même avec d'autres opérateurs tiers) a pour résultat une distortion claire des règles du jeu : si vous êtes chez l'opérateur historique de bout en bout, vous êtes rétabli en 2 jours. Dans le cas contraire, chacun se renvoit la balle pendant un bon mois...

Free n'ouvre un GAMOT qu'après avoir vérifié l'équipement, très certainement à cause des coûts facturés par l'opérateur pour le traitement du GAMOT, dans les cas où le problème viendrait du matériel ou d'un problème de connection au domicile. Pourquoi pas, sauf qu'il faut compter une bonne semaine pour avoir un rendez-vous avec un technicien...
L'opérateur historique va de son côté faire le minimum, à savoir tester la synchro,  puisque généralement cela suffit pour détecter un pb de connection, bien évidemment sans régler votre problème de débit !

La question qui se pose à ce point, c'est de savoir s'il n'y a pas dans ce protocole d'intervention une volonté active ou passive de favoriser les clients de l'operateur historique ? On ne parle pas évidemment de l'incapacité de l'opérateur alternatif à fournir un service après-vente digne de se nom, faute de disposer du personnel suffisant...

A ce point, après un mois sans service, il convient de se poser la question du recours en justice, éventuellement dans le cadre d'une "action de groupe" - puisque c'est aujourd'hui chose possible en France - pour sortir de ces parties de ping-pong infernales ! Mais sauf à condamner lourdement les opérateurs, pour les forcer à réduire ces délais inaceptable, je ne vois pas comment les choses pourraient évoluer.

Mais ne rêvez pas, même dans cette hypothèse, la procédure prendra des années... Il faudra d'abord s'adresser à une société de défense des consommateurs agréée (il y en a 17), et espérer qu'elles acceptent de lancer la procédure. Cela ne préjuge en rien des délais d'obtention d'un jugement - sans compter qu'il peut être rendu en faveur des opérateurs -, sachant que ces derniers peuvent évidemment faire appel, se pourvoir en cassation...

Cela dit, il y a un moment où l'inaction vaut acceptation...