C'est une très grande nouvelle pour les outils de Supervision Libres tels que Nagios (http://www.nagios.org ), Centreon (http://www.centreon.com ) ou FAN, Fully Automated Nagios (http://fannagioscd.sf.net ) et tous les autres. En effet, cela pouvait être un frein dans le déploiement d'un outil de Supervision Libre de ne pas pouvoir superviser la partie matérielle d'un serveur sur une (ou plusieurs) distribution(s) Linux. Pouvoir installer les agents matériels HP sur la majorité des distributions va faciliter d'autant plus la migration vers un outil de supervision Libre.
Je vois que les distributions CentOS et Debian sont intégrées et les demandes que nous avions étaient souvent liées à ces deux distributions. L'intégration d'Ubuntu est une excellente nouvelle car depuis quelques temps les demandes commençaient à affluer pour Ubuntu. Il manque cependant Mandriva, c'est dommage et j'espère qu'elle sera bientôt intégrée.
Ça vient plus du site donc...
Je ne le pense pas car selon l'auteur du journal: Avec un autre serveur DNS (il y en a un certain nombre d'ouvert), pas de souci
OpenNMS est plus axé grandes plateformes.
Ha? Qu'appelle-t'on "Grandes plateformes"? Si on parle de milliers d'équipements supervisés et de dizaine de milliers d'indicateurs alors Centreon/Nagios n'a pas à rougir.
le système d'alerting est plutôt complet.
Celui de Centreon/Nagios est très complet:
- mail SMS, jabber ;
- jours ouvrés/non ouvrés
- période de backup, de reboot, d'interruption régulière de service
- escalades vers de multiples groupes
- jours fériés, congés des utilisateurs, ...
Il intègre une gestion RRD qui évite de s'appuyer sur cacti.
Tout comme Centreon/Nagios
Enfin, il gère nativement les escalades et les plannings de maintenance.
Tout comme Centreon/Nagios.
Le seul argument que j'ai vu de valable est celui là: "module d'auto-discovery". De par mon expérience, c'est à la fois un avantage et un inconvénient. L'inconvénient: l'administrateur est contraint de déclarer tous les éléments à superviser, ce qui peut être fastidieux. L'avantage: l'administrateur est contraint de déclarer tous les éléments à superviser, ce qui lui donne un grand contrôle en lui permettant de ne sélectionner que ce qu'il veut.
A supposer que Centreon comble les lacunes de Nagios, je dirais simplement qu'OpenNMS comble les lacunes de Centreon.
Je n'ai trouvé aucun argument valable pour affirmer cela. Je ne connais pas bien OpenNMS et je ne permettrais jamais d'affirmer que Centreon n'a aucun manque de fonctionnalité ni, surtout, qu'OpenNMS voit ses lacunes comblées par Centreon.
Je pense qu'il est faux de dire que Centreon est un logiciel "fauxpensource", Centreon est un vrai Logiciel Libre pour les raisons suivantes:
- il n'y a pas une version "libre" et une version "entreprise" mais une seule version totalement libre
- Centreon seul, sans ses modules propriétaires, se suffit à lui même : il n'est pas obligatoire d'acheter une licence pour disposer d'une "vraie" version totalement fonctionnelle
- Centreon seul, sans ses modules propriétaires, répond à de nombreux besoins: interface web de configuration, intégration des graphiques RRDTool, configuration graphique des trappes SNMP, reporting, ...
- les contributeurs extérieurs sont les bienvenus (d'ailleurs, qu'ils n'hésitent surtout pas à venir nous aider, on les attend :-) )
PS: je précise pour être totalement transparent, oui je travaille dans la société MERETHIS, qui édite Centreon et ses modules associés
Et il n'y a pas que cela qui a été fait grâce au fork. Il y a aussi:
- un collecteur d'idées pour Nagios: http://ideas.nagios.org
- un bugtracker (refusé pendant très longtemps): http://tracker.nagios.org
- migration de CVS vers GIT
- de nombreux patchs ont été intégrés (dans la version GIT pour le moment)
- le wiki a été mis à jour
- des tests unitaires sur le code ont été intégrés
1) Pour préciser, il s'avère que la société Netways a déposé la marque Nagios en Allemagne. Cette dommage car, en théorie, la marque Nagios est détenue par Ethan non par cette société. Bref, cela semble mal parti pour initier un rapprochement dans le futur.
2) Le développement va être ouvert à d'autres. Des commit vont pouvoir être faits par plusieurs personnes, des patches vont être intégrés. Bref il devrait y avoir un meilleur temps de réponse. Ce qui est une très bonne chose et va dans le bon sens.
3) Les patches réalisés par le projet Icinga vont être intégrés dans Nagios s'ils sont considérés comme étant de bonne qualité et s'ils apportent quelque chose de positif.
Pour résumer, l'effet « coup de pied au cul » semble avoir fonctionné.
En fait je me suis mal exprimé peut être. Je vais essayer de détailler un peu plus. Ce bug est le suivant. Je vais prendre un exemple simpliste pour expliquer.
Un utilisateur de Nagios le configure pour faire une vérification de bon fonctionnement d'une base de données toutes les 5 minutes (connexion à la base de données avec un couple login/mot de passe et requête SQL). En fait ce test est un peu plus complexe: le test est configuré pour ne pas avoir lieu le 1er dimanche de chaque mois entre 3h et 5h car c'est la période de sauvegarde à froid de la base de données. La base de données étant indisponible et cela étant un comportement prévu il n'est pas nécessaire d'envoyer une alarme durant cette période.
Il s'avère que le test s'arrête bien entre 3h et 5h le 1er dimanche du mois mais, sans que l'on comprenne pourquoi aujourd'hui, au lieu de redémarrer dès 5h il est programmé pour l'année 2010. Pour traduire: la base de données n'est plus supervisée! Et cela est (quasiment) invisible. Ce qui est très très gênant
Ce fork était attendu. J'en avais discuté pas mal autour de moi et de nombreuses personnes avaient la même impression: ceci devait arriver. Les raisons sont les suivantes:
- il existe un bug très très gênant dans la version actuelle de Nagios: certains tests ne sont plus réalisés car programmés dans le futur (en 2010)! Gros point faible pour un scheduler.
- ce bug est présent depuis 2008.
- il n'y a aucune communication de la part du développeur principal. Les seuls messages qu'ils envoient sont: les nouvelles versions avec le changelog et (quand il le fait) «merci pour le patch. Je l'intègre bientôt au CVS. » Le problème? Il envoie ces prises en compte de patch 2 voire 3 mois après la réception du patch sur la mailing-list. Dommage non?
- aucune autre personne ne peut prendre le relais du développeur principal. Nagios est un logiciel à code source Libre mais une seule personne ne peut commiter sur le code.
Apparemment, ceux qui ont lancés ce fork ont tenté d'aider le développeur principal: test de patches, utilisation de GIT pour l'intégration de patches, ... Mais ils n'ont pas été écoutés.
Bref il fallait s'y attendre. Cela ne m'étonne pas.
Mon interprétation est la suivante:
1. il n'est pas déconseillé d'utiliser l'Open Source.
2. il est déconseillé d'utiliser l'Open Source si les élèves, leurs enseignants voire l'établissement souhaitent garder un monopole[...].
Je trouve le parallèle très très... cavalier. Mais en même temps, tu es en droit de te poser la question. Cherchons donc quelques informations sur Alix Cazenave et forgeons nous notre propre opinion.
Selon sa biographie disponible sur le site de l'APRIL, elle dispose de diplômes renommés. Elle a fait une "École internationale de commerce et développement" (EICD 3A) puis un master "Ingénierie de l'information, de la décision et de la connaissance". Cela me semble compatible avec sa mission aujourd'hui. De plus, elle a été assistance parlementaire durant 2 ans (2005-2007). Ce qui signifie qu'elle a été en contact avec des députés. Elle doit avoir un réseau de connaissances politiques importants. Ce qui me semble là aussi correspondre au profil recherché.
> Quel est l'interêt de faire une distribution dédiée ?
Nous nous sommes posés la question. Nous avons trouvé des arguments contre. Le premier est que nous souhaitons mettre en oeuvre quelque chose de très très intégré, de dédié. Par exemple pour Nagios, nous avons ajouté un thème à l'interface. Nous "imposons" certains choix pour offrir quelque chose de vraiment intégré, un "tout" logique. La remarque que l'on nous fait souvent à propos de Nagios est "c'est plein de petits logiciels à installer". FAN est une distribution identifiée pour ce besoin.
Le second argument est le PRA. Avec FAN, pour mettre en place un PRA il "suffit" d'avoir deux choses:
- une politique de sauvegarde des données utiles
- une documentation de restauration de ces données
FAN permet de ré installer très rapidement un serveur (OS +applicatifs supervision). Ensuite, il reste à développer la procédure de restauration. Ce dernier point n'est pas prévu dans FAN car nous ne voulions pas gérer tous les outils de sauvegarde existants. Nous laissons ce travail à Mme Michul'administrateur compétent.
Le dernier argument est que nous allons ajouter des outils communs qui seront dédiés à la supervision dans FAN. Prenons l'exemple de Dokuwiki. Cet outil (formidable!) va être utilisé dans FAN pour lier un équipement supervisé avec une procédure de reprise sur panne. Comment gérer ce cas dans une distribution multi-utilisations? Prenons l'exemple de CentOS: comment intégrer un dokuwiki supervision et un autre? Comment gérer simplement le fait que le wiki peut être utiliser à la fois pour la supervision avec des besoins très très précis et de manière beaucoup plus générique?
Avec ces contraintes, nous sommes partis sur une autre distribution. Cependant, nous pourrions revenir en arrière. En effet, nous avons réellement voulu nous concentrer sur la supervision. Tous les paquets externes à FAN proviennent de CentOS. Nous ne les modifions pas. En cas de changement de politique, nous proposerions bien évidemment les paquets à CentOS (ou autre distribution basée sur RPM).
> Je serais tenté de dire que cette distrib répond à un non besoin.
J'ai envie de dire "pour l'instant". En effet, le but premier de FAN est de simplifier l'installation de tous les outils et de fournir une distribution prête à l'emploi. Mais pas en direction de Mme Michu qui n'aura que faire d'installer Nagios (d'ailleurs: le connaît-elle cet outil?), mais en direction d'administrateur systèmes et réseaux qui souhaitent mettre en place une plate forme de supervision rapidement. Ensuite, ces personnes, lorsqu'elles veulent vraiment connaître l'outil, qu'elles n'hésitent pas à installer d'autres composants et à les configurer.
Je disais "pour l'instant" car il est prévu d'étendre FAN. Notamment, pour la version 2.0, il est prévu un fonctionnement multi serveurs, un peu dans le mode de fonctionnement des architectures 3-Tiers: base de données, central (pour la consultation) et collecteur (serveurs de supervision interrogeant les éléments supervisés). Nous avons aussi pour ambition de connecter FAN avec le couple OCS/GLPI notamment pour la gestion de ticket mais aussi pour l'auto détection. Nous travaillons le sujet dans tous les cas.
# Intégration d'outil de supervision Libre plus facile
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse à la dépêche Les serveurs HP et les distributions Linux communautaires. Évalué à 2.
Je vois que les distributions CentOS et Debian sont intégrées et les demandes que nous avions étaient souvent liées à ces deux distributions. L'intégration d'Ubuntu est une excellente nouvelle car depuis quelques temps les demandes commençaient à affluer pour Ubuntu. Il manque cependant Mandriva, c'est dommage et j'espère qu'elle sera bientôt intégrée.
Un grand bravo pour cette initiative.
[^] # Re: chez moi
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal Hadopi ou ?. Évalué à 2.
Je ne le pense pas car selon l'auteur du journal:
Avec un autre serveur DNS (il y en a un certain nombre d'ouvert), pas de souci
[^] # Re: Nagios vs OpenNMS
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse à la dépêche OpenNMS passe en version 1.7.4. Évalué à 1.
Ha? Qu'appelle-t'on "Grandes plateformes"? Si on parle de milliers d'équipements supervisés et de dizaine de milliers d'indicateurs alors Centreon/Nagios n'a pas à rougir.
le système d'alerting est plutôt complet.
Celui de Centreon/Nagios est très complet:
- mail SMS, jabber ;
- jours ouvrés/non ouvrés
- période de backup, de reboot, d'interruption régulière de service
- escalades vers de multiples groupes
- jours fériés, congés des utilisateurs, ...
Il intègre une gestion RRD qui évite de s'appuyer sur cacti.
Tout comme Centreon/Nagios
Enfin, il gère nativement les escalades et les plannings de maintenance.
Tout comme Centreon/Nagios.
Le seul argument que j'ai vu de valable est celui là: "module d'auto-discovery". De par mon expérience, c'est à la fois un avantage et un inconvénient. L'inconvénient: l'administrateur est contraint de déclarer tous les éléments à superviser, ce qui peut être fastidieux. L'avantage: l'administrateur est contraint de déclarer tous les éléments à superviser, ce qui lui donne un grand contrôle en lui permettant de ne sélectionner que ce qu'il veut.
A supposer que Centreon comble les lacunes de Nagios, je dirais simplement qu'OpenNMS comble les lacunes de Centreon.
Je n'ai trouvé aucun argument valable pour affirmer cela. Je ne connais pas bien OpenNMS et je ne permettrais jamais d'affirmer que Centreon n'a aucun manque de fonctionnalité ni, surtout, qu'OpenNMS voit ses lacunes comblées par Centreon.
[^] # Re: Nagios vs OpenNMS
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse à la dépêche OpenNMS passe en version 1.7.4. Évalué à 2.
Je pense qu'il est faux de dire que Centreon est un logiciel "fauxpensource", Centreon est un vrai Logiciel Libre pour les raisons suivantes:
- il n'y a pas une version "libre" et une version "entreprise" mais une seule version totalement libre
- Centreon seul, sans ses modules propriétaires, se suffit à lui même : il n'est pas obligatoire d'acheter une licence pour disposer d'une "vraie" version totalement fonctionnelle
- Centreon seul, sans ses modules propriétaires, répond à de nombreux besoins: interface web de configuration, intégration des graphiques RRDTool, configuration graphique des trappes SNMP, reporting, ...
- les contributeurs extérieurs sont les bienvenus (d'ailleurs, qu'ils n'hésitent surtout pas à venir nous aider, on les attend :-) )
PS: je précise pour être totalement transparent, oui je travaille dans la société MERETHIS, qui édite Centreon et ses modules associés
# Grâce au fork...
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal Nagios devcon #1 : Niiiiiinnnnjjjjjjaaaaaaa. Évalué à 5.
Icinga: http://www.icinga.org
Et il n'y a pas que cela qui a été fait grâce au fork. Il y a aussi:
- un collecteur d'idées pour Nagios: http://ideas.nagios.org
- un bugtracker (refusé pendant très longtemps): http://tracker.nagios.org
- migration de CVS vers GIT
- de nombreux patchs ont été intégrés (dans la version GIT pour le moment)
- le wiki a été mis à jour
- des tests unitaires sur le code ont été intégrés
Bref, ça avance, ça avance. De quoi se réjouir.
[^] # Re: fork ... oui mais ....
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal ICINGA : Un fork de Nagios. Évalué à 1.
1) Pour préciser, il s'avère que la société Netways a déposé la marque Nagios en Allemagne. Cette dommage car, en théorie, la marque Nagios est détenue par Ethan non par cette société. Bref, cela semble mal parti pour initier un rapprochement dans le futur.
2) Le développement va être ouvert à d'autres. Des commit vont pouvoir être faits par plusieurs personnes, des patches vont être intégrés. Bref il devrait y avoir un meilleur temps de réponse. Ce qui est une très bonne chose et va dans le bon sens.
3) Les patches réalisés par le projet Icinga vont être intégrés dans Nagios s'ils sont considérés comme étant de bonne qualité et s'ils apportent quelque chose de positif.
Pour résumer, l'effet « coup de pied au cul » semble avoir fonctionné.
[^] # Re: Attendu... pour certains raisons
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal ICINGA : Un fork de Nagios. Évalué à 4.
Un utilisateur de Nagios le configure pour faire une vérification de bon fonctionnement d'une base de données toutes les 5 minutes (connexion à la base de données avec un couple login/mot de passe et requête SQL). En fait ce test est un peu plus complexe: le test est configuré pour ne pas avoir lieu le 1er dimanche de chaque mois entre 3h et 5h car c'est la période de sauvegarde à froid de la base de données. La base de données étant indisponible et cela étant un comportement prévu il n'est pas nécessaire d'envoyer une alarme durant cette période.
Il s'avère que le test s'arrête bien entre 3h et 5h le 1er dimanche du mois mais, sans que l'on comprenne pourquoi aujourd'hui, au lieu de redémarrer dès 5h il est programmé pour l'année 2010. Pour traduire: la base de données n'est plus supervisée! Et cela est (quasiment) invisible. Ce qui est très très gênant
# Attendu... pour certains raisons
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal ICINGA : Un fork de Nagios. Évalué à 8.
- il existe un bug très très gênant dans la version actuelle de Nagios: certains tests ne sont plus réalisés car programmés dans le futur (en 2010)! Gros point faible pour un scheduler.
- ce bug est présent depuis 2008.
- il n'y a aucune communication de la part du développeur principal. Les seuls messages qu'ils envoient sont: les nouvelles versions avec le changelog et (quand il le fait) «merci pour le patch. Je l'intègre bientôt au CVS. » Le problème? Il envoie ces prises en compte de patch 2 voire 3 mois après la réception du patch sur la mailing-list. Dommage non?
- aucune autre personne ne peut prendre le relais du développeur principal. Nagios est un logiciel à code source Libre mais une seule personne ne peut commiter sur le code.
Apparemment, ceux qui ont lancés ce fork ont tenté d'aider le développeur principal: test de patches, utilisation de GIT pour l'intégration de patches, ... Mais ils n'ont pas été écoutés.
Bref il fallait s'y attendre. Cela ne m'étonne pas.
[^] # Re: Migration depuis la version 1
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal Fully Automated Nagios version 2.0b1 est disponible. Évalué à 2.
Pas dans cette version. Elle devrait être intégrée dans la version béta 2 de FAN.
[^] # Re: Mise à jour du schéma de base
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal Fully Automated Nagios (FAN) est disponible en version 1.1. Évalué à 1.
# Il n'est pas déconseillé de partager à l'école
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal Il est déconseillé de partager à l'école.... Évalué à 9.
1. il n'est pas déconseillé d'utiliser l'Open Source.
2. il est déconseillé d'utiliser l'Open Source si les élèves, leurs enseignants voire l'établissement souhaitent garder un monopole[...].
La nuance est de taille non?
[^] # Re: en fait ...
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse au journal Comment blanchir de l'argent avec une associations d'utilité publique. Évalué à 3.
Selon sa biographie disponible sur le site de l'APRIL, elle dispose de diplômes renommés. Elle a fait une "École internationale de commerce et développement" (EICD 3A) puis un master "Ingénierie de l'information, de la décision et de la connaissance". Cela me semble compatible avec sa mission aujourd'hui. De plus, elle a été assistance parlementaire durant 2 ans (2005-2007). Ce qui signifie qu'elle a été en contact avec des députés. Elle doit avoir un réseau de connaissances politiques importants. Ce qui me semble là aussi correspondre au profil recherché.
Après avoir lues quelques unes de ses interviews, elle me semble défendre tout à fait correctement les intérêts du Logiciel Libre:
* http://www.april.org/fr/causerie-du-9-decembre-2008-sur-lapr(...) : Causerie APRIL
* http://www.pcinpact.com/actu/news/39887-alix-cazenave-april-(...) : interview par PC INPACT
* http://au.youtube.com/watch?v=v9C2_SqlDW4 : interview par Tristan Nitot
* http://www.april.org/alix-cazenave-explique-pourquoi-lassoci(...) : interview par APRIL
* http://www.ecrans.fr/April-Le-grand-public-prend,5260.html : interview sur Ecrans.fr
* http://www.pcinpact.com/actu/news/46254-paris-capitale-libre(...) : un commentaire d'Eric BESSON: Éric Besson était présent au diner de remise des Lutèce d'Or et, lors de son discours d'introduction, il a tenu à saluer « la fougue des représentants et représentantes du logiciel libre » et notamment Alix Cazenave, de l'April, il a précisé à son sujet, sur un ton humoristique : « je tremble lorsque je sais que je vais rencontrer Alix Cazenave, car je sais que je dois préparer mon argumentaire ».
Bref, je pense que ton parallèle n'est pas correct si tu n'apportes aucun fait.
[^] # Re: Quel est l'interêt de faire une distribution dédiée ?
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse à la dépêche FAN : Fully Automated Nagios. Évalué à 6.
Nous nous sommes posés la question. Nous avons trouvé des arguments contre. Le premier est que nous souhaitons mettre en oeuvre quelque chose de très très intégré, de dédié. Par exemple pour Nagios, nous avons ajouté un thème à l'interface. Nous "imposons" certains choix pour offrir quelque chose de vraiment intégré, un "tout" logique. La remarque que l'on nous fait souvent à propos de Nagios est "c'est plein de petits logiciels à installer". FAN est une distribution identifiée pour ce besoin.
Le second argument est le PRA. Avec FAN, pour mettre en place un PRA il "suffit" d'avoir deux choses:
- une politique de sauvegarde des données utiles
- une documentation de restauration de ces données
FAN permet de ré installer très rapidement un serveur (OS +applicatifs supervision). Ensuite, il reste à développer la procédure de restauration. Ce dernier point n'est pas prévu dans FAN car nous ne voulions pas gérer tous les outils de sauvegarde existants. Nous laissons ce travail à Mme Michul'administrateur compétent.
Le dernier argument est que nous allons ajouter des outils communs qui seront dédiés à la supervision dans FAN. Prenons l'exemple de Dokuwiki. Cet outil (formidable!) va être utilisé dans FAN pour lier un équipement supervisé avec une procédure de reprise sur panne. Comment gérer ce cas dans une distribution multi-utilisations? Prenons l'exemple de CentOS: comment intégrer un dokuwiki supervision et un autre? Comment gérer simplement le fait que le wiki peut être utiliser à la fois pour la supervision avec des besoins très très précis et de manière beaucoup plus générique?
Avec ces contraintes, nous sommes partis sur une autre distribution. Cependant, nous pourrions revenir en arrière. En effet, nous avons réellement voulu nous concentrer sur la supervision. Tous les paquets externes à FAN proviennent de CentOS. Nous ne les modifions pas. En cas de changement de politique, nous proposerions bien évidemment les paquets à CentOS (ou autre distribution basée sur RPM).
[^] # Re: En voilà une initiative qu'elle est bonne
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse à la dépêche FAN : Fully Automated Nagios. Évalué à 7.
http://www.linagora.com
(les développeurs de FAN y travaillent ;-) )
[^] # Re: simplicité ?
Posté par Cédric Temple (site web personnel, Mastodon) . En réponse à la dépêche FAN : Fully Automated Nagios. Évalué à 3.
J'ai envie de dire "pour l'instant". En effet, le but premier de FAN est de simplifier l'installation de tous les outils et de fournir une distribution prête à l'emploi. Mais pas en direction de Mme Michu qui n'aura que faire d'installer Nagios (d'ailleurs: le connaît-elle cet outil?), mais en direction d'administrateur systèmes et réseaux qui souhaitent mettre en place une plate forme de supervision rapidement. Ensuite, ces personnes, lorsqu'elles veulent vraiment connaître l'outil, qu'elles n'hésitent pas à installer d'autres composants et à les configurer.
Je disais "pour l'instant" car il est prévu d'étendre FAN. Notamment, pour la version 2.0, il est prévu un fonctionnement multi serveurs, un peu dans le mode de fonctionnement des architectures 3-Tiers: base de données, central (pour la consultation) et collecteur (serveurs de supervision interrogeant les éléments supervisés). Nous avons aussi pour ambition de connecter FAN avec le couple OCS/GLPI notamment pour la gestion de ticket mais aussi pour l'auto détection. Nous travaillons le sujet dans tous les cas.