Blog Odyssée

Dans un précédent billet, je citais un tweet de Jacques Lucas :

@Jcqslucas :
@p_ameline Y a-t-il un chemin éthique entre le Tout État et la Jungle?Ou entre L’Etat providence et la non protection medico-sociale?

Pour lever tout doute sur le fait que sa question n’était pas une interrogation, mais une interpellation, il a, en réponse, précisé sa pensée :

@Jcqslucas :
@p_ameline Belles réflexions. Mais, quand je pose la question sur le chemin, c’est que je pense qu’il existe. Il faut prendre ce chemin là.

Il faut donc prendre ce chemin là ; entre les extrêmes… mais quel chemin ?

Faisons un petit détour par deux autres tweets qui se sont intercalés dans le fil de discussion :

@cmattler :
@Jcqslucas @p_ameline Sachant qu’il y a une infinité de chemins entre ces deux extrêmes, cela reviendrait à dire qu’il n’y a plus d’éthique

@cmattler :
@Jcqslucas @p_ameline ou qu’il ne faut pas chercher l’éthique dans le chemin, mais dans les pas de ceux qui l’emprunteront…

Magie de Twitter (et de son exigence de « pensée condensée ») ; en quelques mots voici dessiné un paysage propice à réflexion éclairée :

• Les attracteurs massifs que sont le tout état et le non état cachent une multitude de chemins intermédiaires.
• Les chemins intermédiaires ne sont pas encore tracés, mais ils peuvent naître des besoins vrais de leurs usagers

C’est désormais une approche classique quand on crée un ensemble architectural de ne pas créer les chemins à l’avance et d’attendre que, des circulations naturelles sur les pelouses, se dessinent les axes de circulation à aménager.

Plus l’environnement est complexe et plus l’échec est garanti pour celui qui pense qu’il connait la solution à l’avance et peut la cristalliser avant mise en service.

Proposition résumée dans un récent tweet provocant de Dominique Dupagne :

@Web_Neuronal
Sur les médias sociaux, validation du concept bio qui m’est cher : mieux vaut agir avant de réfléchir http://bit.ly/mPZxBc

Ne croyez pas que Dominique Dupagne agisse vraiment avant de réfléchir… il exprime ici le fait que, dans les univers à forte plasticité, le résultat d’une action modifie (parfois fortement) l’environnement environnant. Le temps de conception et de développement d’une solution « finalisée » est alors trop long à l’échelle de la vitesse d’évolution du biotope cible… et lorsque cet édifice sera prêt à implanter, il sera presque toujours anachronique dans le nouveau paysage.

On pourra argumenter sur le fait que dans le domaine qui nous préoccupe, il est habituel de penser que l’état est légitime à imposer des solutions monopolistiques et que la quasi-absence de mouvement donne l’illusion d’un glacis intangible. C’est un mirage, car si le domaine ne voit pas sa surface modelée en permanence par la réponse à des solutions innovantes, il est, du fait de l’évolution réelle des besoins de la population, le lieu de changements souterrains profonds. Les tensions considérables qui s’accumulent en sous-sol rendent illusoire la mise en œuvre de tout système massif.

En réponse à la caricaturale plasticité du Web, une démarche est en cours de formalisation aux états-Unis : le « lean ».

Le lean répond à la problématique ancienne, qui a fait naître les méthodologies « agiles », que la plupart des solutions informatiques échouent parce que le développement en cascade qui étudie les besoins avant rédaction d’un cahier des charges, obtention d’un budget puis appel d’offre de développement, développement et recette donne naissance à des systèmes de piètre qualité et inadaptés.
Le défaut de qualité provient à la fois de la trop grande complexité initiale du projet dans un cadre budgétaire fixé artificiellement, ce qui est très peu propice à la mise en place de la couche qualitative (épine dorsale de tests unitaires et fonctionnels).
L’inadaptation est liée à la fois à la perte de substance dans la chaîne de réalisation (qui sait réellement exprimer ses besoins ? qui sait les transformer fidèlement en un cahier des charges ? qui sait construire une solution fidèle dans la lettre et l’esprit ?) et, comme je l’ai déjà exprimé, au fait que, entre le moment où le futur utilisateur exprime ses besoins et le moment où le système est livré (typiquement plusieurs années), le besoin a considérablement évolué.

La réponse « agile » est d’intégrer le futur utilisateur dans l’équipe de développement et, grâce à des cycles de développement très courts, de lui permettre de guider l’évolution selon ses besoins réels. En utilisant réellement un système initialement très simple mais dont il commande les axes d’évolution « à l’usage réel », il a de grandes chances d’investir son budget dans des fonctions réellement utiles. Par ailleurs, cette contrainte pour l’équipe de développement de devoir suivre un client opportuniste oblige à la mise en place d’une démarche qualitative qui restera une garantie d’évolutivité du système final.

Le Lean est une généralisation de ces concepts de base à un univers considérablement élargi. Les entrepreneurs du Web ont constaté que la démarche ancienne, qui passait par la longue et difficile réalisation d’un plan d’affaires afin de convaincre des acteurs du capital-risque d’investir massivement pour financer une équipe de développement posait deux problèmes majeurs : pour convaincre les financeurs du sérieux du projet, il fallait concevoir un système « bourré de fonctions » et, compte tenu du temps passé à écrire le business plan, à chercher le financement et à transformer le tout en centaines de millier de lignes de codes… le train était presque toujours parti entre temps. Le Web avait changé, des concurrents directs ou indirects étaient déjà en place… et le capital risqueur, parfaitement conscient de la situation, avait déjà coupé les vivres.

La réponse est désormais classique : concentrer son idée en 5 fonctions et la mettre en ligne. Ensuite, être très attentif aux réactions des utilisateurs et faire évoluer le système en cycles rapides (parfois un par jour).

Il serait naïf de penser que le Lean est facile et garantit le succès. Les systèmes de contrôle qualité doivent être extrêmement sophistiqués, et il faut savoir réagir très rapidement aux demandes des utilisateurs tout en gardant une vision « tête haute » de la direction globale. Pour un « voileux » comme moi, c’est somme toute assez naturel : il faut s’adapter de façon rapide et opportuniste aux facéties du plan d’eau tout en ayant une idée assez précise – mais qui reste fortement modifiable – du chemin à parcourir.

Pourra-t-on appliquer le Lean à l’univers de la santé ? C’est, à mon sens, la seule méthode actuellement à notre disposition pour ne pas échouer à coup sûr.

Les obstacles sont nombreux, principalement liés à la totale inadaptation des services de l’état à une approche qui ne soit pas en cascade – ce qui est, entre autres, lié à notre système de lois écrites.

L’autre risque majeur, dans un système qui doit posséder une forte capacité de déformation dans la recherche de la forme optimale, c’est que certains acteurs conçoivent leur pratique comme immuable, que ce soit par incapacité à s’extraire de paradigmes usés jusqu’à la corde ou par respect obligé des obligations éthiques qui encadrent ces usages anciens.

C’est un domaine où l’Ordre des Médecins peut jouer un rôle particulièrement délétère (en limitant l’espace de recherche à des optimums locaux situés à courte distance des usages immémoriaux), ou, au contraire, extrêmement positif en prenant la responsabilité de contribuer à l’encadrement éthique d’axes d’exploration atypiques (qui seront assez naturellement concurrents des solutions officielles).

L’honorable représentant de l’Ordre explicitement à l’origine de ce billet se retrouve implicitement à sa conclusion. Souhaitons que soient fécondes les réflexions qu’il fait actuellement naître au sein de cette organisation.

This entry was posted on Saturday, June 18th, 2011 at 10:19 am and is filed under Français, General, Public health information systems. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.