Discussion:Maintien en condition opérationnelle

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

Je pense qu'il faudrait ajouter l'activité de maintien d'applications informatiques. Corrections de faits techniques et évolutions de systèmes d'information, le terme est de plus en plus utilisé. Le terme TMA est utilisé mais le T (Tierce) fait référence au fait que l'on peut récupérer la maintenance d'un système développé par un tiers, alors que la MCO est plutôt relative aux applications développées par ses propres services. — Le message qui précède, non signé, a été déposé par 80.13.152.167 (discuter)

Orthographe[modifier le code]

"maintien en condition opérationnelle" (titre) ou "maintien en conditions opérationnelles" (corps de l'article) ? — Le message qui précède, non signé, a été déposé par 212.23.175.190 (discuter)

Le maintien en conditions opérationnelles va bcp plus loin, et dépasse le PCA.
Avant de gérer le passage en mode dégradé il y a lieu de "faire" du MCO (suivi d'indicateurs de fonctionnement, gestion des configuration, veille technique, veille obsolescence, assistance, gestion des faits techniques, réparations, etc... — Le message qui précède, non signé, a été déposé par 195.101.137.157 (discuter)

Rien à voir[modifier le code]

Je ne suis pas en phase avec l'article. le MCO consiste à maintenir en fonctionnement une application dans son contexte technique (ou son écosystème) qui évolue perpétuellement. Ce contexte comprend tout ce qui gravite autour de l'application, réseau, hardware, software, middleware etc... mais pas l'application elle même. La mise en place de la bascule comme évoquée dans l'article ne fait pas partie du MCO. Son exécution si nécessaire fait parti du MCO. — Le message qui précède, non signé, a été déposé par Nicolas julie (discuter)

Si des modifications, des corrections doivent être apportées à la page, il faut impérativement qu'elles reposent sur des sources, et de qualité (livres, articles de revues), et non sur des avis personnels non étayés. --Elnon (d) 7 juillet 2012 à 16:26 (CEST)[répondre]

Je rejoins l'avis ci-dessus. Le MCO tel que je le pratique ne correspond pas à cette définition. Pour répondre à Elnon qui demande des sources, je propose le rapport de la cour des comptes de décembre 2004 "Le maintien en condition opérationnelle des matériels des armées" qui définit ainsi le MCO dans le cadre de l'armée :
"Le maintien en condition opérationnelle peut être défini comme l’ensemble des moyens et procédures nécessaires pour qu’un matériel reste, au long de sa durée d’utilisation, apte à l’emploi qui lui est assigné. La notion de maintien en condition opérationnelle des matériels recouvre deux types de fonctions. La première est le soutien technique qui regroupe trois grandes catégories d’opérations :
- la maintenance proprement dite, comprenant les actions visant à maintenir (ou rétablir) un équipement dans un état spécifié (telles que les carénages pour l’entre tien des coques des bateaux, la reconstitution du potentiel d’heures de vol d’un aéronef ou le changement de moteur d’un char) ;
- la gestion de configuration des équipements qui permet de suivre l’évolution de la définition technique des matériels au long de leur vie opérationnelle ;
- la tenue à jour des référentiels techniques, mais aussi l’analyse du retour d’expérience issue de l’exploitation des faits techniques. La deuxième fonction est le soutien logistique
. Elle comprend les opérations d’approvisionnement des rechanges, la maintenance de ceux-ci, leur magasinage (stockage) et le ravitaillement en pièces de rechange des unités, des structures de soutien (ateliers industriels) voire, dans certains cas, des industriels.
La maintenance peut s’exercer suivant deux modes distincts :
- la maintenance préventive qui correspond à l'ensemble des opérations à caractère systématique ou conditionnel, définies pour chaque type de matériel et destinées à prévenir les altérations ou à limiter leur développement, de façon à maintenir les matériels aptes à l'emploi ;
- la maintenance corrective qui concerne les opérations ayant pour but de remédier aux avaries survenues en fonctionnement ou aux altérations décelées au cours de la maintenance. "
Cette définition peut être étendue sans problème à tout matériel, système ou logiciel.--PascalP (d) 22 juillet 2013 à 23:43 (CEST)[répondre]

Votre lien ne fonctionne pas. --Elnon (d) 23 juillet 2013 à 08:30 (CEST)[répondre]
Lien corrigé. --PascalP (d) 25 juillet 2013 à 21:26 (CEST)[répondre]
Merci. D'accord pour que ces éléments soient intégrés dans la page. --Elnon (d) 25 juillet 2013 à 22:21 (CEST)[répondre]

A développer[modifier le code]

Je ne modifie pas la page parce qu'il s'agit surtout d'un avis personnel. Je fais partie d'une équipe nommée "MCO", mais, dans ma boite, il mélangent peut-être plusieurs choses ? Quoiqu’il en soit je n'ai pas de citations pour étayer, du moins pour l'instant.

Comme cité plus haut, je pense également que la MCO va beaucoup plus loin : Détection/correction d'anomalies logicielles et reprises/redressements de données y compris. Il s'agit de maintenir ou redonner le fonctionnement attendu du logiciel suite à une évolution qui aurait pu avoir un effet de bord ou, le plus souvent, un impact non détecté lors de l'étude d'évolution; voir même une MEP ratée.

La fonction de la MCO est de :

1) Déterminer si le problème remonté comme anomalie est bien une anomalie et non un fonctionnement correct par rapport aux spécifications du client.

2) S'il s'agit d'une anomalie, la corriger; On chiffre alors le diagnostique et le développement (la correction) en MCO.

Si le fonctionnement n'est pas "correct" fonctionnellement parlant, mais pourtant conforme au cahier des charges, remonter l'information aux analystes fonctionnels pour qu'ils précisent leurs specs. Alors seulement, selon les cas, corriger ou carrément considérer qu'il s'agit d'une évolution (en général c'est ce qui arrive lorsque l'impact est lourd). Si la mise à jour est considérée comme évolution, alors c'est l'équipe développement qui s'en charge et non la MCO. Si la correction est mineure, alors l'équipe MCO peut faire l'effort de le faire, malgrès cela, les heures passées seront chiffrées comme évolution auprès du client, seul le diagnostique sera chiffré en MCO.

3) Opérer des redressements SQL ou autre patchs "data", pour remettre les données telles que le système aurait dû les positionner si il n'y avait pas eu anomalie (mais ceci n'est pas toujours nécessaire, par exemple pour un bête bug d'affichage)

Toujours idem plus haut, la mise en place de bascule fait plutôt partie de la conception de plateforme (haute dispo, mais surtout FAIL OVER pour le principe de la bascule). Pour les grands projets, une fois en production (donc au moment ou on trouve de la MCO; simple précision : on ne maintien pas la condition opérationnelle d'un système qui n'est pas encore opérationnel) il s'agit là d'une préoccupation (la bascule) plus attribuée à l'équipe production/exploitation qu'à l'équipe MCO. C'est à l'exploit' de surveiller la supervision et contrôler l’éventuel démarrage de la plateforme de secours. Il est rare que la TMA ait accès direct aux plateformes de production (Je pense notamment au secteur bancaire, et au secteur public). — Le message qui précède, non signé, a été déposé par 81.66.144.229 (discuter), le 2 décembre 2012 à 08:40