Victime du système de télétransmission de la sécurité sociale

Tout informaticien qui se respecte a au moins une fois dans sa vie eu une attitude méprisante envers le profane qui se retrouve victime du méchant système informatique. Nous autres informaticien avons tendance à croire que les programmes que nous faisons sont parfaits et que seule la mauvaise intervention de l’utilisateur est la cause des problèmes. La réalité est tout autre.

En effet les systèmes deviennent de plus en plus complexes et sont inter-connectés. Il en va de même des processus. Prenez l’exemple du système de télé-transmission de la sécurité sociale. A priori c’est un système pratique qui évite à l’assuré d’avoir à envoyer à sa mutuelle des demande de remboursement. Cela fonctionne à priori bien mais que se passe-t-il au cas limites ? Que se passe-t-il quand on change de département et d’organisme complémentaire ? Que se passe-t-il quand par une intervention divine l’usager ne peut plus se faire rembourser à cause d’un “bug” du système ?

Le système de télé-transmission présente à mon sens des failles d’ordre structurel. En effet ce sont les organisme complémentaires qui viennent se greffer sur le système de la caisse primaire et qui décide d’enregistrer ou de supprimer un bénéficiaire pour la télé-transmission. La caisse primaire est un simple exécutant. Lorsque par malheur un bénéficiaire se retrouve avec 2 mutuelles dans les fichiers de la sécurité sociale, le système se bloque: aucune mutuelle ne veut plus rembourser. L’usager est alors invité à se rapprocher de la caisse primaire qui même si elle est le conservateur de l’information refusera sur demande de l’usager la suppression des “mutuelles parasites”. C’est un comble l’usager paye il doit avoir le pouvoir!

La procédure pour s’en sortir est de présenter à la sécurité sociale les certificats de radiation des mutuelles ce qui prouve bien que se sont les mutuelles qui ont le pouvoir d’empêcher par parasitage le remboursement de l’usager. Le processus normal du point de vue de l’usager payeur c’est que l’usager et lui seul doit pouvoir sur simple demande autoriser et associer une mutuelle à un bénéficiaire. Or le processus exclut totalement l’usager qui se retrouve à quémander la normalisation d’une situation dont il n’est pas responsable et pourtant dont il paye les frais ou plutôt dont on ne le rembourse pas.

Ce cas présenté montre à quel point la mise en place de système informatique soit disant pour le bien être de l’usager, se heurte à la limite inéluctable de la finitude de l’homme et de son esprit. Tout système informatique trouvant sa limite, l’usager c’est-à-dire l’homme devrait toujours rester le maître. Avis donc aux informaticiens: quand vous rencontrez un utilisateur qui se plaint du système, mettez vous à sa place car c’est pour lui que vous travaillez.

Victime du système de télétransmission de la sécurité sociale

Tout informaticien qui se respecte a au moins une fois dans sa vie eu une attitude méprisante envers le profane qui se retrouve victime du méchant système informatique. Nous autres informaticien avons tendance à croire que les programmes que nous faisons sont parfaits et que seule la mauvaise intervention de l’utilisateur est la cause des problèmes. La réalité est tout autre.

En effet les systèmes deviennent de plus en plus complexes et sont inter-connectés. Il en va de même des processus. Prenez l’exemple du système de télé-transmission de la sécurité sociale. A priori c’est un système pratique qui évite à l’assuré d’avoir à envoyer à sa mutuelle des demande de remboursement. Cela fonctionne à priori bien mais que se passe-t-il au cas limites ? Que se passe-t-il quand on change de département et d’organisme complémentaire ? Que se passe-t-il quand par une intervention divine l’usager ne peut plus se faire rembourser à cause d’un “bug” du système ?

Le système de télé-transmission présente à mon sens des failles d’ordre structurel. En effet ce sont les organisme complémentaires qui viennent se greffer sur le système de la caisse primaire et qui décide d’enregistrer ou de supprimer un bénéficiaire pour la télé-transmission. La caisse primaire est un simple exécutant. Lorsque par malheur un bénéficiaire se retrouve avec 2 mutuelles dans les fichiers de la sécurité sociale, le système se bloque: aucune mutuelle ne veut plus rembourser. L’usager est alors invité à se rapprocher de la caisse primaire qui même si elle est le conservateur de l’information refusera sur demande de l’usager la suppression des “mutuelles parasites”. C’est un comble l’usager paye il doit avoir le pouvoir!

La procédure pour s’en sortir est de présenter à la sécurité sociale les certificats de radiation des mutuelles ce qui prouve bien que se sont les mutuelles qui ont le pouvoir d’empêcher par parasitage le remboursement de l’usager. Le processus normal du point de vue de l’usager payeur c’est que l’usager et lui seul doit pouvoir sur simple demande autoriser et associer une mutuelle à un bénéficiaire. Or le processus exclut totalement l’usager qui se retrouve à quémander la normalisation d’une situation dont il n’est pas responsable et pourtant dont il paye les frais ou plutôt dont on ne le rembourse pas.

Ce cas présenté montre à quel point la mise en place de système informatique soit disant pour le bien être de l’usager, se heurte à la limite inéluctable de la finitude de l’homme et de son esprit. Tout système informatique trouvant sa limite, l’usager c’est-à-dire l’homme devrait toujours rester le maître. Avis donc aux informaticiens: quand vous rencontrez un utilisateur qui se plaint du système, mettez vous à sa place car c’est pour lui que vous travaillez.

Solution propriétaire dans l’atelier de production logicielle Java

Il est courant de faire l’éloge des outils open source dans l’atelier de production logicielle au travers de Maven ou Eclipse, mais est-ce par idéologie ou par raison économique ou bien par réel intérêt ? N’existe-t-il pas des cas où les solutions propriétaires constituent un alternative judicieuse ?

Nous entendons par atelier de production logiciel ou usine de production logiciel, l’ensemble des composants techniques et processus permettant de réaliser le logiciel. Cela va des outils de spécification, de modélisation aux outils de contrôle de la qualité en passant par les outils de développement. Il est indéniable que là où se battaient pléthore éditeurs comme Symantec ou Borland, ne subsiste aujourd’hui qu’un ou deux acteurs commerciaux tel que IBM tellement les solutions open source sont devenues  légions. Mais derrière cette percée de l’open source il se cache peut-être une disparité de l’offre.

Nous pouvons distinguer plusieurs domaines suivant l’usage de l’outil en commençant par la phase de conception et de spécification. Les AGL (Atelier de Génie Logiciel) sont un domaine où l’open source est très peu présent et ne peut rivaliser avec les offres payantes. Les fonctions de round-trip (aller-retour entre le code et le modèle) ainsi que la prise en charge de technologie d’implémentation (EJB, Webservice) sont l’apanache des solutions propriétaires payantes. Au contraire le domaine des outils de build et les IDE sont le terrain de jeux de l’open-source. Le système de build Ant est devenu le standard à l’intérieur de nombreux IDE, même propriétaires. Mais aujourd’hui ce système de build est vieillissant et sera supplanté par Maven dont les principaux IDE commencent à s’accommoder et il n’est pas nécessaire de s’appesentir sur la “part de marché” d’Eclipse dans les IDE. Enfin l’autre bout du spectre, celui du contrôle de la qualité au travers des outils d’intégration continue et de tests automatiques est mitigé. L’intégration continue est un concept avancé du génie logiciel que les éditeurs n’ont pas encore exploité laissant le champ libre à l’open source avec CruiseControl par exemple. A l’inverse le concept de test d’intégration est très industrialisé les éditeurs sont présents avec par exemple TestDirector.

Finalement c’est la partie centrale constituée du developpement et un peu de la phase suivante que l’open source occupe réellement dans l’atelier de production logiciel. La présence de brique propriétaire est donc encore nécessaire.

Cette situation va-t-elle évolué ? Pour les idéalistes de l’open source il serait de bon ton que les récents efforts pour intégrer des fonctionnalité UML directement aux IDE se poursuivent a l’instar de Netbeans . Ainsi la première phase de l’atelier sera conquise. Reste à savoir si le phase d’intégration évoluera vers une prise en charge complète par l’open source. Je tiens le pari que oui. L’histoire a montré que la valeur ajoutée de l’informatique s’est déplacée du matériel au logiciel et aujourd’hui elle se déplace du logiciel au service. Les éditeurs de logiciels non personnalisés que ce soit des logiciels outils ou pas sont bien concurrencés par l’open source comme le montre OpenOffice. Les éditeurs de logiciel devront faire du sur-mesure ou offrir du service d’expertise. Les raisons pour lesquels cette évolution me semble inéluctable est que la pression sur les coûts pousse à une rationalisation des dépenses. L’entreprise préfère utiliser chaque euro du budget du projet dans la création de fonctionnalité à valeur ajoutée donc la pression sur les coûts des outils fait tourner l’entreprise vers des solutions open-source gratuites. Cela réduit les revenus des éditeurs d’outils propriétaires qui pour assurer leur rentabilité ont tendance à réutiliser des solutions open-source maquillées dans leur produit.

Solution propriétaire dans l’atelier de production logicielle Java

Il est courant de faire l’éloge des outils open source dans l’atelier de production logicielle au travers de Maven ou Eclipse, mais est-ce par idéologie ou par raison économique ou bien par réel intérêt ? N’existe-t-il pas des cas où les solutions propriétaires constituent un alternative judicieuse ?

Nous entendons par atelier de production logiciel ou usine de production logiciel, l’ensemble des composants techniques et processus permettant de réaliser le logiciel. Cela va des outils de spécification, de modélisation aux outils de contrôle de la qualité en passant par les outils de développement. Il est indéniable que là où se battaient pléthore éditeurs comme Symantec ou Borland, ne subsiste aujourd’hui qu’un ou deux acteurs commerciaux tel que IBM tellement les solutions open source sont devenues  légions. Mais derrière cette percée de l’open source il se cache peut-être une disparité de l’offre.

Nous pouvons distinguer plusieurs domaines suivant l’usage de l’outil en commençant par la phase de conception et de spécification. Les AGL (Atelier de Génie Logiciel) sont un domaine où l’open source est très peu présent et ne peut rivaliser avec les offres payantes. Les fonctions de round-trip (aller-retour entre le code et le modèle) ainsi que la prise en charge de technologie d’implémentation (EJB, Webservice) sont l’apanache des solutions propriétaires payantes. Au contraire le domaine des outils de build et les IDE sont le terrain de jeux de l’open-source. Le système de build Ant est devenu le standard à l’intérieur de nombreux IDE, même propriétaires. Mais aujourd’hui ce système de build est vieillissant et sera supplanté par Maven dont les principaux IDE commencent à s’accommoder et il n’est pas nécessaire de s’appesentir sur la “part de marché” d’Eclipse dans les IDE. Enfin l’autre bout du spectre, celui du contrôle de la qualité au travers des outils d’intégration continue et de tests automatiques est mitigé. L’intégration continue est un concept avancé du génie logiciel que les éditeurs n’ont pas encore exploité laissant le champ libre à l’open source avec CruiseControl par exemple. A l’inverse le concept de test d’intégration est très industrialisé les éditeurs sont présents avec par exemple TestDirector.

Finalement c’est la partie centrale constituée du developpement et un peu de la phase suivante que l’open source occupe réellement dans l’atelier de production logiciel. La présence de brique propriétaire est donc encore nécessaire.

Cette situation va-t-elle évolué ? Pour les idéalistes de l’open source il serait de bon ton que les récents efforts pour intégrer des fonctionnalité UML directement aux IDE se poursuivent a l’instar de Netbeans . Ainsi la première phase de l’atelier sera conquise. Reste à savoir si le phase d’intégration évoluera vers une prise en charge complète par l’open source. Je tiens le pari que oui. L’histoire a montré que la valeur ajoutée de l’informatique s’est déplacée du matériel au logiciel et aujourd’hui elle se déplace du logiciel au service. Les éditeurs de logiciels non personnalisés que ce soit des logiciels outils ou pas sont bien concurrencés par l’open source comme le montre OpenOffice. Les éditeurs de logiciel devront faire du sur-mesure ou offrir du service d’expertise. Les raisons pour lesquels cette évolution me semble inéluctable est que la pression sur les coûts pousse à une rationalisation des dépenses. L’entreprise préfère utiliser chaque euro du budget du projet dans la création de fonctionnalité à valeur ajoutée donc la pression sur les coûts des outils fait tourner l’entreprise vers des solutions open-source gratuites. Cela réduit les revenus des éditeurs d’outils propriétaires qui pour assurer leur rentabilité ont tendance à réutiliser des solutions open-source maquillées dans leur produit.

La VoIP en mobilité

De nombreux téléphones portables offrent une connectivité Wifi dont l’usage est multiple. Dès qu’un réseau sans fil est à porté, le premier usage est l’accès au web pour la consultation de site ou de messagerie. Un autre usage moins populaire mais qui gagne à être connu est la VoIP. Je ne parle pas de solution propriétaire comme Skype mais plutôt de réseau ouvert qui utilise le protocole SIP. Nous allons nous attarder sur ce dernier.

Tous d’abord commençons par préciser les avantages de la VoIP avec SIP. Ce protocol permet d’enregistrer un terminal (le téléphone ou un ordinateur) sur le réseau internet et de l’associer à une adresse SIP qui est l’équivalent du numéro de téléphone classique. Cela permet d’appeler et d’être joignable à partit d’un même numéro SIP. A la maison on utilise un terminal qui par exemple est un véritable téléphone puis au bureau on peut utiliser un logiciel (appelé softphone). Un correspondant utilise alors le même numéro pour nous joindre. Si on est enregistrer sur le réseau SIP à la maison, c’est le téléphone de la maison qui sonne. Si on est enregistré par le biais du téléphone logiciel, alors c’est l’ordinateur qui sonne.

Cela confère la caractéristique bien connue de mobilité déjà présente dans les téléphones portables. Et c’est ici que la VoIP prend justement tout son intérêt. Le téléphone portable devenant de plus en plus puissant, intègre aujourd’hui en natif ou par ajout d’un logiciel comme par exemple Gizmo, la fonction de téléphone SIP qui couplé à la connectivité Wifi, permet de passer des appels en mobilité par internet. La téléphonie IP devient alors plus attrayante que le résau cellulaire car utiliser par une borne Wifi (gratuite) pour passer des appels par SIP est bien moins onéreux.

Mais la VoIP est-t-elle réellement utilisable ? En effet on associe souvent au terme VoIP, des appels par internet et cela ramène au concept pourtant réducteur d’appel d’ordinateur à ordinateur. A quoi bon avoir un téléphone portable Wifi utilisant le protocole SIP si on ne peux pas joindre des téléphones classiques ? De même à quoi bon avoir un terminal Wifi si il n’y a pas de borne Wifi exploitable là où on se trouve ? Ces 2 questions ne sont à mon avis aujourd’hui plus des obstacles car d’une part les points d’accès “gratuits” se multiplient à l’instart du réseau FON et la liaison entre téléphonie IP et réseau classique existe sous diverse forme.

Intéressons nous au réseau Wifi lui même. Le maillage du réseau Wifi est le problème principale. En effet la mobilité en réseau cellulaire est acquise car les opérateurs on installé partout leurs antennes. Or un simple coup d’oeil sur la carte FON nous rassure sur le maillage d’un réseau gratuit. L’accès en Wifi au réseau internet n’est donc pas un problème insurmontable. Quand à la passerelle entre SIP et le réseau classique, c’est un écueil que l’on évite en s’affranchissant d’une somme modique au regard du tarif pratiqué par le réseau téléphonque classique mais réellement compétitif par rapport au tarif des opérateurs IP comme Free ou Neuf. En effet ni Skype ou Gizmo ne sont en mesure de rivaliser aujourd’hui avec les offres tarifaire de Free avec par exemple la liaison avec les ligne fixe gratuite.

L’astuce est alors d’utiliser le compte SIP de son opérateur résidentiel afin de bénéficier de ses tarifs en mobilité. Je pense que là les opérateurs de téléphonies cellulaires sont face à une réelle menace que pour l’instant ils contournent en interdisant le VoIP avec leurs offres internet sur les mobiles. Pour l’utilisateur ce n’est pas bloquant. Il utilise le reseau wifi gratuit pour passer ses appel SIP.

Dans cette perspective j’ai essayé avec bonheur l’utilisation de mon compte SIP Free depuis mon téléphone Wifi en me connectant à une borne Wifi d’un inconnu. Ce dernier utilisait il est vrai Free comme fournisseur ce qui explique que le point d’accès Wifi était pré-configuré pour en permettre l’usage aux autres abonnés. Il me reste à faire un test depuis un point d’accès FON pour terminer la démonstration mais elle me suffit déjà. La VoIP en mobilité est aujourd’hui possible car les terminaux sont disponibles, le maillage du réseau Wifi est suffisant et la passerelle vers le réseau classique est soit accessible soit donnée par le fournisseur d’accès résidentiel.

La VoIP en mobilité

De nombreux téléphones portables offrent une connectivité Wifi dont l’usage est multiple. Dès qu’un réseau sans fil est à porté, le premier usage est l’accès au web pour la consultation de site ou de messagerie. Un autre usage moins populaire mais qui gagne à être connu est la VoIP. Je ne parle pas de solution propriétaire comme Skype mais plutôt de réseau ouvert qui utilise le protocole SIP. Nous allons nous attarder sur ce dernier.

Tous d’abord commençons par préciser les avantages de la VoIP avec SIP. Ce protocol permet d’enregistrer un terminal (le téléphone ou un ordinateur) sur le réseau internet et de l’associer à une adresse SIP qui est l’équivalent du numéro de téléphone classique. Cela permet d’appeler et d’être joignable à partit d’un même numéro SIP. A la maison on utilise un terminal qui par exemple est un véritable téléphone puis au bureau on peut utiliser un logiciel (appelé softphone). Un correspondant utilise alors le même numéro pour nous joindre. Si on est enregistrer sur le réseau SIP à la maison, c’est le téléphone de la maison qui sonne. Si on est enregistré par le biais du téléphone logiciel, alors c’est l’ordinateur qui sonne.

Cela confère la caractéristique bien connue de mobilité déjà présente dans les téléphones portables. Et c’est ici que la VoIP prend justement tout son intérêt. Le téléphone portable devenant de plus en plus puissant, intègre aujourd’hui en natif ou par ajout d’un logiciel comme par exemple Gizmo, la fonction de téléphone SIP qui couplé à la connectivité Wifi, permet de passer des appels en mobilité par internet. La téléphonie IP devient alors plus attrayante que le résau cellulaire car utiliser par une borne Wifi (gratuite) pour passer des appels par SIP est bien moins onéreux.

Mais la VoIP est-t-elle réellement utilisable ? En effet on associe souvent au terme VoIP, des appels par internet et cela ramène au concept pourtant réducteur d’appel d’ordinateur à ordinateur. A quoi bon avoir un téléphone portable Wifi utilisant le protocole SIP si on ne peux pas joindre des téléphones classiques ? De même à quoi bon avoir un terminal Wifi si il n’y a pas de borne Wifi exploitable là où on se trouve ? Ces 2 questions ne sont à mon avis aujourd’hui plus des obstacles car d’une part les points d’accès “gratuits” se multiplient à l’instart du réseau FON et la liaison entre téléphonie IP et réseau classique existe sous diverse forme.

Intéressons nous au réseau Wifi lui même. Le maillage du réseau Wifi est le problème principale. En effet la mobilité en réseau cellulaire est acquise car les opérateurs on installé partout leurs antennes. Or un simple coup d’oeil sur la carte FON nous rassure sur le maillage d’un réseau gratuit. L’accès en Wifi au réseau internet n’est donc pas un problème insurmontable. Quand à la passerelle entre SIP et le réseau classique, c’est un écueil que l’on évite en s’affranchissant d’une somme modique au regard du tarif pratiqué par le réseau téléphonque classique mais réellement compétitif par rapport au tarif des opérateurs IP comme Free ou Neuf. En effet ni Skype ou Gizmo ne sont en mesure de rivaliser aujourd’hui avec les offres tarifaire de Free avec par exemple la liaison avec les ligne fixe gratuite.

L’astuce est alors d’utiliser le compte SIP de son opérateur résidentiel afin de bénéficier de ses tarifs en mobilité. Je pense que là les opérateurs de téléphonies cellulaires sont face à une réelle menace que pour l’instant ils contournent en interdisant le VoIP avec leurs offres internet sur les mobiles. Pour l’utilisateur ce n’est pas bloquant. Il utilise le reseau wifi gratuit pour passer ses appel SIP.

Dans cette perspective j’ai essayé avec bonheur l’utilisation de mon compte SIP Free depuis mon téléphone Wifi en me connectant à une borne Wifi d’un inconnu. Ce dernier utilisait il est vrai Free comme fournisseur ce qui explique que le point d’accès Wifi était pré-configuré pour en permettre l’usage aux autres abonnés. Il me reste à faire un test depuis un point d’accès FON pour terminer la démonstration mais elle me suffit déjà. La VoIP en mobilité est aujourd’hui possible car les terminaux sont disponibles, le maillage du réseau Wifi est suffisant et la passerelle vers le réseau classique est soit accessible soit donnée par le fournisseur d’accès résidentiel.

Ubuntu pour développer en Java ?

Cette distribution linux rendue célèbre en 2006 par son interface graphique sexy 3D offre l’avantage d’être orientée utilisateur : une installation simple, des logiciels complets et un support des codec non libres. Ubuntu une distribution parfaite pour qui souhaite quitter Windows pour Linux.

Aujourd’hui  la toute dernière version 8.04 offre un support complet pour le développement Java. Le dépôt de paquet contient les outils nécessaires. En premier lieu le JDK 5 et 6 peut être obtenu directement à partir du gestionnaire de paquet. L’éditeur Java de référence, celui de Sun, est également disponible : Netbean 6. Enfin l’outil de build incontournable pour avoir des projets modulaires, Maven 2, est aussi présent.

netbeans.1209841312.pngmaven2.1209841298.pngjdk.1209841286.png

Cela constitue un confort appréciable pour peu que les mises à jour soient régulières et n’oblige pas à revenir à la méthode manuelle qui reste toujours possible si le besoin est d’avoir plusieurs versions des applications en même temps ou des versions spécifiques mais n’enlève en rien l’intérêt d’un support natif des outils de développement Java.

Ubuntu pour développer en Java ?

Cette distribution linux rendue célèbre en 2006 par son interface graphique sexy 3D offre l’avantage d’être orientée utilisateur : une installation simple, des logiciels complets et un support des codec non libres. Ubuntu une distribution parfaite pour qui souhaite quitter Windows pour Linux.

Aujourd’hui  la toute dernière version 8.04 offre un support complet pour le développement Java. Le dépôt de paquet contient les outils nécessaires. En premier lieu le JDK 5 et 6 peut être obtenu directement à partir du gestionnaire de paquet. L’éditeur Java de référence, celui de Sun, est également disponible : Netbean 6. Enfin l’outil de build incontournable pour avoir des projets modulaires, Maven 2, est aussi présent.

netbeans.1209841312.pngmaven2.1209841298.pngjdk.1209841286.png

Cela constitue un confort appréciable pour peu que les mises à jour soient régulières et n’oblige pas à revenir à la méthode manuelle qui reste toujours possible si le besoin est d’avoir plusieurs versions des applications en même temps ou des versions spécifiques mais n’enlève en rien l’intérêt d’un support natif des outils de développement Java.