Avenir dans les nuages ou avenir nuageux ?

La semaine dernière ont eu lieu les grandes joutes des dieux du Cloud : Marc Bennioff et Larry Ellison se sont affrontés à Paris à deux jours d'intervalle dans un pugillat verbal des plus acérés.


Ce qu'il fallait retenir tient en quelques points :

• Le Cloud c'est l'avenir !
• Le Cloud ce n'est pas de la virtualisation !
• Le Cloud est mort, vive le Cloud2 !
• Quest-ce que le Cloud2 ?! Réponse : L'extension du Cloud aux réseaux sociaux !
• Pourquoi autant de « ! ». Réponse : Parce que !!!

Le logiciel comme un service plutôt que comme un produit. Sans sarcasme, en voilà une idée qu'elle est bonne !
Jusqu'à présent, un fournisseur de service tel un opérateur de télécommunication ou un fournisseur d'électricité, mettait à disposition des usagers, un service consommable imédiatement et facturable à l'usage ou au forfait. Peut-on placer le logiciel dans cette catégorie d'usage ?
Pour ceux que la programmation a amené vers l'informatique (et non l'inverse), la règle n°5 de Rob Pike, stipule que les données prévalent sur le logiciel. Cette maxime a été adoptée depuis quelques décénnies pour construire des logiciels sous forme de données structurées et d'un habillage fonctionnel.
Celui qui détient le logiciel, détiendrait les données. On préfère donc être propriétaire de son logiciel puisque l'on veut rarement partager ces données : commerciales, stratégiques, financières ou personnelles.
Le Cloud, qui n'est autre qu'un socle mutualisé hébergeant des logiciels à usage d'utilisateurs, deviendrait implicitement un coffre-fort pour leurs données. Est-ce que cela a de l'avenir et pour quel genre d'usage?
Toute institution bien établie, garante des données de ces clients (banque, assureur...), ne peut déléguer cette garantie à une institution tierce. Le risque d'une défaillance existe dans les deux cas, mais la délégation diluant les responsabilités, des sanctions seraient compliquées à appliquer. Le trouble social qui s'en suivra impliquera l'intervention des états qui ne peuvent se permettre une telle situation car... too big to fail !
Il reste tous les autres usages, non soumis à une obligation légale : TPI, PMI/PME et autres services publiques peu critiques. Pour ceux là, pas d'interventionnisme car... too small to be relevant !
Ce genre de service intéresse donc les petites structures, disposant de peu de moyens d'investissement et acceptant de fait, le risque que représente un tel modèle logiciel. Nous savons depuis peu que ces utilisateurs sont presque aussi nombreux en volume de marché que les grandes institutions du CAC40 ou du Fortune 500.
Ce modèle économique devenu populaire depuis 2004, a bouleversé notre perception du marché. Cette longue traine statistique intéresse tous les exclus du modèle fermé traditionnel.
Marc Bennioff a concrétisé son idée en 1999, cinq ans avant le fameux article de Chris Anderson. Le génie, c'est donc cela : créer l'usage qui fera naître le modèle !

Condom Architect

J'ai eu ces derniers jours à réfléchir sur le métier d'architecte. L'éternel incompris de l'informatique, à cheval entre le savant-cosinus et le super-admin. Un rôle indéfinissable et nécessaire, mais nécessaire à quoi?!
En tout cas on entendra fatalement à un moment donné d'un projet, ce cri "munchien" de désespoir: De grâce, un architecte!!! Un cri qui arrive généralement lorsque le projet amorce la pente douce progressivement raide vers le gouffre de sa fin déshonorrante.

Quelques questions pour commencer :
Est-ce qu’un bon spécialiste peut faire un bon architecte ?
Un bon spécialiste dans une équipe d’architecte ne risque t-il pas de devenir… un bon spécialiste dans une équipe d’architecte ?

Cela m'amène à me poser la question : Qu’est ce qu’un architecte ? (ou qu’est-ce qu’il n’est pas ?)
Sans être aussi caricatural que Martin Fowler dans sa description du "Matrix Reloaded Architect", voici ce que pourrait être une charte d'architecte:

• Ne pas écrire de scripts, de code Java ou C/C++, ou résister à l'envie de le faire. Se placer plutôt comme mentor en donnant des normes et des bonnes pratiques et rappeler que le développement est un art. Ce qui suppose d’être bien au dessus des compétences classiques d’un développeur. De temps en temps, mettre les mains dans de cambouï, écrire des portions de code pour accélérer les choses et pour rester crédible (et aussi pour ne pas s'ennuyer!).

• Ne pas exécuter de commandes d’administration ou résister à l'envie de le faire. Donner plutôt un support de (très) haut niveau pour administrer ou analyser un élément du SI : OS, Middleware, logiciel… Pousser les intégrateurs et les administrateurs à être autonômes et à rechercher d'eux même en leur dévoilant quelques astuces méconnues dans leur spécialité.

• Ne pas remplacer le chef de projet mais l’assister à mener à terme son projet, sans le « vampiriser », en ramenant sans cesse le débat sur les éléments clés du projet : objectif métier, délai, budget, intégration au SI et performances contractuelles. Considérer les projets comme des étapes plutôt que des aboutissements.

• Partager, communiquer, évangéliser sur les projets et aussi sur les concepts inhérents au SI, en simplifiant les choses le plus possible, cela évite le rejet et permet l’adhésion des parties prenantes. On adhère à un projet quand on comprend ses dimensions techniques et métier.

D'où la définition suivante:
Un architecte technique est un consultant interne, un référent technique multi-spécialiste (expertise), capable d’expliquer sans donner de leçons (communication, pédagogie et modestie), d’accélérer une réalisation sans se l’approprier (délégation). Il doit planifier, fédérer puis clôturer (gestion).
C’est l’électron libre qui maintien le système en mouvement.

Pour terminer sur un peu de légèreté, j'ai lu récemment une BD satirique dans laquelle un architecte était comparé à un... préservatif! On s'en passerait bien vu sa capacité à enlever tout plasir. Mais quand les choses vont mal, on commence vraiment à regretter de ne pas avoir eu le bon sens de l'utiliser :-)

Culture de café ou culture d'entreprise?

Dans une récente analyse publiée pour Forester, Mike Gualtieri pose une question polémique: Est-ce que Java est une impasse pour les applications d’entreprises?

Une avalanche de commentaires passionnés s'en est suivie sur la toile. Il est vrai que les annonces de Mike ont de quoi titiller les égos: adopté par plus de 70% des grandes entreprises, près de 60 JSR, courbe d'apprentissage croissante, multiplications de frameworks palliatifs et enfin : 68% de projets inaboutis.

L'étude soutient que l'une des causes d'inadéquation de Java pour construire des applications d'entreprises est sa tentative de couvrir tout le spectre des sept qualités d'un logiciel: expérience, disponibilité, performance, échelonnage, adaptabilité, sécurité et économie.

Vouloir atteindre la perfection est certes une preuve d'ambition mais cela montre surtout un manque de pragmatisme, car de toutes ces qualités seulement deux se détachent aujourd'hui comme des tendances: l'expérience utilisateur et l'adaptabilité.
Un logiciel ennuyeux pour les utilisateurs est un échec et si l'on ne peut pas le modifier dans des délais et des coûts raisonnables, alors il disparaîtra. Il se trouve que Java n’a pas été inventé par des spécialistes des applications d’entreprise, d’où la faillite des premières versions d’EJB. Il n’a aussi jamais été pensé pour le confort de l’utilisateur final, d’où l’échec d’AWT puis de Swing et enfin de JSF. Java s'est embourbé dans des modèles inutilement complexes, des architectures "bitte schön, danke schön", comme les décrit Christophe Thiry, de manière hilarante dans son blog.

L’étude met en avant les nouveaux paradigmes de développement. L’avenir, pressenti depuis longtemps mais concrétisé depuis peu, appartient à ceux qui réduiront les délais, les coûts et la distance avec le cœur de métier de l’entreprise. Des architectures événementielles représentent cette nouvelle tendance où différents outils sont employés à différentes phases d’un modèle métier (et non plus d’un programme): conception, implémentation et action. Ces paradigmes offrent beaucoup plus qu'une évolution, ils promettent d'humaniser l'informatique.

Le principal argument mis en avant par les entreprises, pour justifier la continuité de la stratégie Java est… historique : J’ai investit dans Java, j’ai plusieurs applications en production, je suis obligé de supporter ma croix et pour longtemps encore…Cela ne vous rappelle-t-il pas un autre langage. Eh oui, Cobol, toujours là et pour longtemps encore ! De là à dire que Java subira le même sort, il n’y a qu’un pas. Je trouve cependant cette étude rassurante : il y’aura toujours du boulot pour les développeurs Java. Dieu merci !

Eloge de la lenteur

Un article étonnant de Philosophie Magazine chamboule notre rapport au temps et remet en question la paternité de l'horloge.
Tout le monde s'accorde à dire que l'horloge mécanique a été inventée en Europe au XIIIème siècle. Pourtant les chinois disposaient dès le premier millénaire, d'un système de clepsydre très sophistiqué, utilisé principalement dans l'étude du mouvement des astres, savoir nécessaire pour établir les prévisions astrologiques dont l'empereur se servira pour exercer son pouvoir. Le temps selon les chinois est donc un luxe réservé aux décisions de l'empereur. Le peuple quant à lui ne peut disposer de ce privilège. Alors dirons nous, comment prévoir le temps ou comment définir un délai et le respecter? Eh bien sur ce sujet, deux cultures s'opposent: dans l'occident, le temps sert à borner une réalisation par un début et une fin. Dans la civilisation chinoise, le temps importe peu pour une réalisation, seule la perfection compte!
Imaginons ce que serait nos projets dans un monde régit par la perfection et non pas par la "deadline". Nous n'aurions certainement pas des smartphones, mais nous aurions des moyens de communication qui répondent parfaitement à nos besoins sans bugs et sans stress pour les SAV.
Pensez à un travail que vous avez réalisé en prenant votre temps. Imaginez à quoi il aurait pu ressembler si on vous avait imposé de le livrer pour telle-date-au-plus-tard!
Le pouvoir dans la culture occidentale se mesure par la capacité à faire respecter les délais, quelle humiliation que de ne pas livrer en temps et en heure. On préfèrerait produire une immondice et y adjoindre une série de correctifs plutôt que de prendre le temps de tester et de peaufiner. J'ai déjà vu des chefs de projets à la limite de la dépression parce que leur projet risque de prendre du retard. J'ai souvent proposé de prendre le temps de produire quelque chose de correcte plutôt que de se précipiter et de perdre toute crédibilité vis-à-vis des utilisateurs. Eh bien non, rien n'y fait. La seule chose qui restera du projet ce n'est pas l'aventure humaine et technologique, la réalisation innovante ou la satisfaction des clients. Non, tout ce qui sera retenu ce sera le RETARD!
Dans la bande dessinée "Le petit Nicolas" de Sempé et Goscinny, Geoffroy est un garçon décrit comme lunatique et toujours en retard. D'ailleurs la maîtresse ne l'a jamais félicité à cause de son retard, sauf une fois: il venait d'avoir un p'tit frère.
Un long conditionnement qui a débuté sur nos bancs d'école et qui ressort et guide nos comportement d'hommes actifs. Maintenant que la cause est identifiée, levez vous du canapé et reprenez le dessus sur vos vieux démons scolaires!

Bonne année 2011 !

Une nouvelle année est une nouvelle itération dans notre histoire personnelle, un "sprint" de plus dans la réalisation de la fameuse oeuvre, dont on pourra savourer la ligne parfaite, épurée, aboutie... avant de recommencer de plus belle et en mieux. Nous sommes insatiables! En tout cas j'espère pour vous que vous l'êtes, autrement la vie serait insipide!
J’ai récemment découvert le blog d’Olivier Roland, un autodidacte éclairé doué d’un enthousiasme à toute épreuve. Il s’est fixé comme défi de lire 52 livres en 52 semaines ! Cette boulimie de savoir s’explique : combien de fois avez-vous changé d’avis sur un sujet après avoir lu quelque part un court article, découvert par hasard, ou après avoir écouté un débat télévisé. Vous êtes par la suite étonné d’une telle découverte qui a changé quelque chose en vous et vous vous jurez de revenir sur le site ou le blog en question, promesse évidemment non tenue. Combien d’occasions similaires avons-nous raté ? Vous vous résigner et vous vous dites que vous n’avez pas le dont d’ubiquité.
Un conseil : persévérez, lisez le plus possible ! Mais pas n’importe quoi. Olivier Rolland énumère quelques perles documentaires inconnues, pourtant étonnement célèbres, au vu des évaluations Amazon.
Dans le même ordre d’idées, un autre adepte de self-made-man, Josh Kaufman, présente la méthode Personal MBA pour atteindre soit-même un niveau équivalent à celui de MBA, en lisant de manière ciblée un panel de livres sur tous les domaines: économie, organisation, développement personnel, management... etc. Essayez, c'est passionnant et c'est mieux votre compte bancaire!
Donc pour cette nouvelle année, lisez! Autant que vous pouvez ! Pour sortir du nuage de flou dans lequel nous plongent tous les jours, les masses d'informations incertaines. Lisez, vous serez imbuvable quelques temps avec votre science infuse; juste le temps de digérer puis de réorganiser et enfin de piocher, non sans y avoir ajouté une pointe d'humour, dans la mine de savoir dont vous disposerez. Vous serez enfin quelqu'un qu'il sera bon de connaître.
Bonne année encore et n'oubliez pas de faire un geste pour Wikipedia et de relayer le message!

Agile ou contortioniste?

Pourquoi la méthode Agile a du mal à s'imposer dans les projets informatiques?
Une réponse intéressante à cette question a été postée sur le site DZone. L'auteur explique que que le client trop impliqué par Agile, se comporte comme s'il ne voulait pas qu'on lui reproche le disfonctionnement de l'application qu'il a contribué à spécifier. Plus crûment, il ne veut pas être blâmé en cas de problème. D'où vient ce sentiment?
Le plus souvent, une solution informatique en entreprise est imposée plus que choisie. Dès lors, elle cesse d’être une solution pour devenir un fardeau. La vision simplificatrice de l’entité « Client » occulte tous les aspects humains entourant la réalisation d'un projet.
Agile est une méthode pragmatique, bâtie sur l’hypothèse d’un monde faillible et d’un contexte humain contraint et donc peu coopératif et peu constructif par nature. Cette méthode a brisé la linéarité irréaliste de Waterfall en petits incréments, dont le but est de faire apparaître les imperfections, le plus tôt possible.
Voici un exemple type d'un dialogue Agile entre Marlene, du service de Gestion et Fred, un développeur:
F: Voici ma compréhension de ce cas d’utilisation. Êtes-vous d’accord ?
M: Oui.
F: Alors passons à la réalisation…. Qu’en pensez-vous maintenant ?
M: Ce n’est pas bon, vous n’avez pas bien compris ce que je voulais dire.
F: Pourtant je l'ai écrit et vous l’avez relu… Recommençons…. Qu’en pensez-vous maintenant ?
M: C’est beaucoup mieux. Il reste deux trois détails
….
M: Là c’est parfait !
Une fois l’application mise sur rails, on se rend compte que ce cas d’utilisation mérite d’être revu. Il faut refaire appel aux service de Fred et Marlene qui avait validé ce cas, risque d’être pointée du doigt et le vivra mal.
C’est de cette situation que souffre Agile. Le fait que le client s’implique à ce point dans le processus de développement et le risque qu’il en soit blâmé. Ceux qu’on doit blâmer, traditionnellement, ce sont les fournisseurs, non ?! Pourtant Marlene ne devrait pas avoir de soucis à se faire, l'éventualité de redévelopper un cas d'utilisation fait partie d'Agile et ne coûtera pas plus chère à l'entreprise.
Agile remet en question les situations schizophrènes comme par exemple: le client ne maîtrise pas son métier et ne peut pas l'admettre et le fournisseur n'a aucun moyen de lui soutirer des informations et ne peut pas s'en plaindre. Alors on fait avec... Une situation Ubuesque qui a mené en deux décennies, à une belle pagaille dans les SI.
Alors on tente de remplacer cela par un processus qui répartit les responsabilités ou, disons, en crée là où il n’y en avait pas auparavant. Une méthode qui tient compte de l'imperfection des hommes et des logiciels pour peut-être moins de stress inutile dans les projets.
Un projet ne peut être quantifié seulement par une durée, un budget et un taux de cas d’utilisations couverts. Il faudrait y ajouter une composante que nous avons totalement occulté : la sérénité.
J. Stiglitz a introduit un indicateur de « bien être » dans l’évaluation du PIB, ce qui révèle que des pays supposés riches ne le sont pas réellement. Pourquoi ne pas en faire autant pour les projets informatiques ? Cela révèlera peut-être que certains projets sont plus aboutis que d’autres, même si la sacro-sainte « deadline » n’a pas été respectée.

L'interface "est" le système

C'est en tout cas ce qu'affirme Vinayak Hegde dans la liste des 97. Dans cette même liste on peut lire une contribution de Einar Landre qui affirme pour sa part que l'architecte doit se focaliser principalement sur l'interface.
Le premier évoque la relation de l'humain avec le système, le second parle de la relation des systèmes entre eux. Peut-on établir un parallèle?
Dans ces deux affirmations, l'interface joue le rôle d'intermédiaire dans l'établissement de relations.
Dans la culture populaire, un agent intermédiaire peut faire ou défaire une bonne entente, quelle que soit la bonne foi des deux parties.
Pourquoi alors cette confiance en un intermédiaire incontournable? Quelle est la pérennité d'une telle association? Réponse: aucune des parties prenantes à la relation ne veut s'adapter à l'autre, car cette adaptation induit une dépendance. Autrement dit, chaque partie portera en elle, une définition de l'autre. L'intermédiaire devient alors un facilitateur!
Lorsque les systèmes s'interfacent entre eux, on parle de "découplage". Lorsqu'ils s'interfacent avec des humains, on évoque... "l'intuition". Dans les deux cas on fait appel à l'agent adaptateur.
Les systèmes entre eux, pour réduire leur dépendance, sont conçus en faisant appel à des modèles respectant les principes fondamentaux que sont la Séparation des responsabilités et l'inversion de contrôle. Quant à l'humain, sa communication avec le système passe par l'image au sens figuré, que lui retransmettent ses sens. Les interfaces se sont donc adapté à ce mode de communication: vue, ouïe, toucher, (goût et odorat?). Il y a quelques années elles étaient minimalistes: clavier, écran et symboles, ce qui nécessitait un effort cérébral important pour mémoriser l'association des symboles informatiques au monde réel. Au fil des années, de plus en plus de sens sont stimulés et la symbolique disparaît peu à peu: la communication est devenue graphique, s'est colorée, animée et sera bientôt holographique. L'action passait par le clavier, elle est devenue tactile, orale... bientôt télékinétique?
Nous déployons de moins en moins de moyens rationnels pour communiquer avec le système, qui pour sa part nécessite de plus en plus d'intelligence pour rendre possible cette simplification. Ne sommes-nous pas en train de nous atrophier à l'avantage des systèmes que nous concevons?
Disons que notre intelligence change; nous évoluons vers un futur plus heuristique que rationnel.
Un jour, doués de cette nouvelle forme d'intelligence, nous finirons par concevoir des systèmes qui seront intelligents, certes d'une intelligence à l'image de notre passé d'humain atrophié, mais alors une nouvelle étape sera alors franchie, celle où interfaces et systèmes se confondrons.

OWF!

Il y'a quelques jours, a eu lieu l'Open World Forum. Si vous y étiez, vous auriez remarqué que le perfecto en cuir de Simon Phipps tranchait franchement avec le costume-cravate du DSI de Sanofi-Aventis :-)
Il ne s'agissait pas d'une énièmme messe d'évangélisation de l'humanité à la voie sacrée de la FSF, avec RMS en post-babacool, pronant l'amour du software libre et le rejet de la vile monaie! Non, il s'agissait d'un autre type d'évennement, un show orchestré par des acteurs aguerris aux règles du business qui présentaient leurs solutions. De vraies solutions robustes; concurrentes directes de solutions commerciales, pour des utilisations stratégiques en entreprise: Cloud Computing, Virtualisation, BPM, BI, CMS...
Ce forum a soulevé de nombreuses questions de fond:
Comment cette culture, hérétique il y'a dix ans, est-elle devenue aujourd'hui une réelle alternative? Est-ce mimétique ou conjoncturel? Quel est l'avenir du logiciel libre face au logiciel commercial? Comment transformer une solution Open Source en opportunité business?
Je n'ai pas trouvé de réponses à toutes ces questions. J'ai cependant observé que la curiosité a disparu pour laisser place à une véritable adoption, réfléchie et pragmatique. Les DSI présents (Bull, Sanofi-Aventis, Safran, PriceMinister...) se sont tous déclarés comme déjà utilisateurs de solutions Open Source et prêts à considérer les offres; du moment que la performance est au rendez-vous. La révolution appartient déjà à l'histoire!
La gêne perceptible, car il y'en a, est due au fait que l'Open Source expose beaucoup plus la responsabilité des dirigeants. Point de contrat commercial exhorbitant, adossé à des clauses telles que que seules de puissantes firmes logicielles peuvent se permettre de parapher. L'Open Source ramène aux fondements d'un métier, de notre métier: la compétence, la passion, l'honnêteté. Aucun dirigeant n'est sûr de disposer, dans son projet d'intervenants sûrs, partageant ces valeurs. Alors, il préfèrera les firmes. A grand renfort de communication, elles ont imposé à notre subconscient l'image de la perfection. Personne ne reprochera à ce dirigeant de s'être mépris en choisissant une perfection admise par tous.
Seulement voilà, tout cela est en train de changer, la maturité de ce métier explique de moins en moins la délégation de responsabilité. Les défaillances répétées des firmes ont érodé définitivement le mythe de la perfection. Nous redescendons vers une réalité moins brillante: les paradigmes sur lesquels sont construites les nouvelles architectures d'aujourd'hui ont moins de dix ans d'existence. Alors faisons profil bas, dénouons le nœud de notre cravate et comme Simon Phips, revêtons notre blouson en cuir de baroudeur de l'informatique, abandonnons notre égo et tentons de construire, enfin, des systèmes par la seule force de notre intelligence.

L'art de la maquette

Lors d'une visite de la Sagrada Familia à Barcelone, j'ai été frappé par l'audace de Gaudi. Oser reproduire les frondaisons d'une forêt dans une cathédrale pour exprimer des sentiments abstraits: l'élévation, l'origine de la vie, la beauté maîtrisée de la nature et sa copie inachevée par l'homme. Audacieux!
Comment peut-on oser la réalisation d'oeuvres monumentales en gardant une totale assurance dans ces créations? Comment peut-on se permettre de telles audaces?
La réponse je l'ai eu un peu plus loin. Alors que je m'avançait dans la crypte je me suis retrouvé devant une reproduction inversée en structure de fil de fer de la Colonia Guëll. De petites bourses de sables maintenaient les arrêtes vers le bas en augmentaient la courbure de leur arc en fonction de leur poids. Le tout faisait penser à un hologramme sortie d'un logiciel de modélisation d'architecture. Gaudi avait, au début du 20ème siècle, inventé la maquette 3D!
Pourquoi cette structure de maquette complexe alors que du plâtre, comme il était d'usage à son époque, aurait suffit? Les maquettes en dur, il en a construit plusieurs, encore bien conservées à ce jour. Celle qui m'a attiré donnait au visiteur, une sensation de légèreté, une cathédrale immense, flotant dans les airs, comme les colonnes de la Sagrada, semblables à d'immenses arbres dont les sommets s'élèvent vers le ciel pour soutenir le plafond de la cathédrale. Tout un symbole... Gaudi ne voulait pas seulement modéliser une forme, mais un concept! Il tentait d'approcher et de "peaufiner" l'émotion que susciterait son oeuvre une fois terminée.
Lorsque l'on opère un changement dans les systèmes d'informations, nous réalisons ce que nous appelons des POC. Ces derniers, comme leur acronyme l'indique, doivent représenter un concept et non pas un sous ensemble de l'architecture finale. Le plus souvent nous nous contentons d'y tester des procédures d'installation, nous passons ensuite à la réalisation et nous nous étonnons de découvrir d'énormes disfonctionnements pendant le projet. Nous aurons non seulement perdu tout l'intérêt d'un POC, mais en plus, nous scellerons à jamais toute tentative de réarchitecture ou même de compréhension ou de modification future.
La plupart du temps, le système d'information est vu comme un agrégat de logiciels et de matériel plutôt que comme un ensemble de concepts.
Les partisants de SOA honnissent l'architecture en "silos", Je trouve cette image très éloquente... passer du silot à la cathédrale ne revient-il pas à délaisser l'alimentaire pour le spirituel. OK, me direz vous, mais seulement le dimanche!

Corrélation VS Causalité

Un jour, j'ai eu à traiter un incident de production qui s'est déclaré sous la forme d'une application de production qui s'est brusquement ralentie au point de ne plus fonctionner.Dans le même temps, un serveur hébergeant un service utilisé par cette application s'est arrêté de fonctionner.

Déferlement d'e-mails, cacophonie de sonneries de téléphone et confusion généralisée. Que faire?! Quelques redémarrages de services plus loin et le système était reparti tant bien que mal.
De par sa rareté, le problème était difficile à reproduire. Une démarche simpliste dans ce cas, est de tenter plusieurs interventions sur les différents services impliqués, dans différents ordres pour tenter d'en déduire la séquence fatale. Peu efficace. Cette Méthode empirique s'appuie sur la dépendance intuitive entre des phénomènes.
La seule conclusion à laquelle nous aboutissons (permettons nous un peu de probabilités), est que les variables aléatoires correspondant aux éventualités d'occurrence d'un résultat sont liées entre elles plus ou moins fortement. Cette liaison s'exprime, dans la théorie de la probabilité, par une corrélation définie par son coefficient. Plus ce dernier est élevé plus forte est cette liaison.
La corrélation ne suffit pas pour se prononcer sur ce que l'on tente de vérifier réellement: une causalité! La modéliser n'est pas une mince affaire!
Introduisons un autre niveau de probabilité: celui concernant l'occurrence de relations de causalité entre les variables aléatoires. Nous obtenons un graphe (de causalités) et une table de probabilité. Le tout est appelé: réseau Bayésien.
Dans ce graphe les relations de cause à effet ne sont pas déterministes mais probabilistes. Nous n'exprimons plus une cause mais une probabilité précise qu'un effet soit du à cette cause.
Appliqué à notre problème, cela nous aurais permis d'exclure les fausses pistes jusqu'à se rapprocher de l'origine du problème.
Dans une architecture distribuée modélisée par un graphe acyclique fortement connexe, les nœuds représentent des services (ou des serveurs) et les arcs sont les protocoles réseau les reliant. Nous disposons d'une connaissance (le savoir empirique cumulé par notre expérience sur cette architecture) et des inférences (observations intuitives sur notre système). Comment vérifier ces inférences? Posé ainsi, le problème se modélise de lui même en réseau Bayésien.
Combien de fois avons nous entendu des phrases contenant des termes comme: "très probable", "peu probable"... et combien de fois nous en avons été peu convaincus, nous avons cependant refermé le dossier par manque d'outils, mais aussi, avouons le... par paresse ;-)