Distinction du contrat de conseil informatique avec une différence

Clients, Faites Très Attention À Ce Que Vous DemandeZ

Écrit par Duncan C. Card

L’un des aspects les plus importants et les plus fondamentaux de chaque accord de conseil informatique est également l’une des plus grandes sources de malentendu juridique et de risque commercial pour ces transactions. Heureusement, sur la base de mon expérience, cette source trop fréquente et formidable de risque de projet informatique est entièrement (oui, complètement) dans la capacité des clients informatiques à atténuer, sinon à éviter entièrement, si bien géré.

Ces risques commerciaux et juridiques découlent directement d’un malentendu omniprésent, et pourtant d’une simplicité trompeuse, concernant les différences importantes entre un service de consultation « consultatif » et un service de consultation ^{« livrable ».1} L’incapacité d’apprécier et de prendre en compte cette distinction simple, mais profonde, est au cœur de bon nombre des différends et des responsabilités les plus graves qui surviennent dans le cadre de projets de conseil informatique.

Lorsqu’une transaction de conseil informatique est structurée comme un service de conseil, le consultant est engagé pour fournir ses conseils et une assistance experts, expérimentés et professionnels au client à l’appui d’une entreprise particulière ou même pour faciliter un résultat particulier. Bien que des services de conseil puissent être fournis par des autorités mondiales de premier plan dans leurs domaines relatifs, ces mandats ne promettent ni ne garantissent des résultats, des avantages ou des résultats particuliers. Tous les services professionnels de nature consultative doivent respecter les normes prescrites (et souvent onéreuses) de diligence, de qualité et de diligence, que ces normes soient le fait d’un contrat, d’une loi ou de la common law. Cependant, les fournisseurs de services consultatifs n’assument jamais le risque d’un résultat raté (sauf dans la mesure où un tel manquement est causé ou contribué par le non-respect des normes de service professionnelles prescrites) et le consultant ne sera pas responsable de la réalisation ou de l’atteinte des résultats souhaités ou des intentions d’affaires du client.

Voici des exemples courants de services consultatifs (au sens le plus large) : un cabinet d’avocats qui est retenu pour aider une société à acquérir une autre société, ou pour défendre un accusé au procès, ou pour négocier une transaction complexe en suspens; un chirurgien qui est retenu pour enlever un appendice infecté ou pour diagnostiquer une maladie particulière; ou, un consultant en TI qui est retenu pour aider à guider le client à travers le processus prescrit de configuration et de mise en œuvre d’une entreprise complexe logiciel. Dans chaque cas, le fournisseur de services ne garantit pas un résultat particulier, ne promet pas de remède, n’assume pas la responsabilité d’une transaction de fusions et acquisitions ratée et n’accepte pas de servir de police d’assurance du client pour les mauvaises décisions d’affaires du client ou tout jugement erroné qui est entrepris au cours de l’acompte de service. Contrairement à la perception populaire, il n’y a ni intrinsèquement ni nécessairement aucune responsabilité associée à l’opération ratée d’un chirurgien, à un diagnostic erroné, ou même pour ne pas avoir retiré un instrument chirurgical d’un patient après une opération. Au contraire, tant que ce chirurgien a fait tout ce qu’un chirurgien raisonnablement diligent et prudent aurait dû faire dans des circonstances comparables, alors aucune responsabilité n’incombera au chirurgien pour l’échec du résultat souhaité de ce patient à être atteint. ² Par analogie avec de telles obligations professionnelles de diligence dans la profession médicale, sous réserve du respect par le consultant de toutes les obligations de diligence applicables dans l’exécution des services, les résultats des services de consultation en TI qui sont strictement de nature consultative, seront entièrement le risque du client.

D’autre part, les accords de services de conseil dits « livrables » ont (à bien des égards) beaucoup en commun avec les accords d’achat de produits. Dans de telles transactions livrables, un consultant est engagé pour fournir bien plus que de simples conseils, une assistance et des conseils pratiques en garantissant qu’un résultat, un résultat ou un avantage spécifique ou particulier sera livré au client. Par analogie, d’autres dispositifs de retenue livrables pourraient comprendre : la réparation d’un toit afin qu’il ne fuit pas et qu’il ne fuit pas avant 10 ans; ou, de construire la maison en conformité complète avec les exigences détaillées du plan architectural, des rapports d’ingénierie et des spécifications de conception intérieure. Dans de telles transactions, l’exécution réussie d’un accord de conseil ne peut être déterminée que par une correspondance directe avec la nature, la portée et l’étendue précises de la façon dont le « livrable » est défini dès le départ. Étant donné que ces transactions sont axées sur la production du produit livrable défini, la qualité professionnelle des services n’est pas pertinente (et n’est pas un facteur dans toute évaluation des risques ou de la responsabilité) tant que le résultat pour lequel le contrat est conclu a été livré conformément au contrat.

D’après mon expérience, c’est le non-respect contractuel des démarcations claires en droit et en commerce entre les services « de conseil » et les services « livrables » où les clients des services de conseil informatique ne parviennent le plus souvent pas à gérer correctement leurs projets de conseil et les risques de transaction. En tant que question fondamentale de distinction juridique (et de responsabilité), les risques de l’un ou l’autre type de transaction peuvent être gérés bien dans les limites de leurs contextes commerciaux et de risque extrêmement différents. Cependant, toute confusion contractuelle entre (ou parmi) ces contextes de risque très divergents conduira très probablement à une incapacité à gérer les risques de l’un ou l’autre type de transaction, laissant le client et le consultant exposés de manière vulnérable aux risques involontaires du projet. Malheureusement, les clients qui ne sont pas en mesure (pour de nombreuses raisons) de matérialiser leurs attentes autrement vagues ou subjectives en un résultat bien défini et clairement articulé ou un « livrable » souvent à tort (et dangereusement) veulent structurer leur approvisionnement en conseil informatique comme un « livrable » plutôt que plus prudemment et correctement comme un service de conseil consultatif. En fait, la tendance à forcer un consultant informatique à des obligations de service qui semblent exiger des obligations « livrables » sans être en mesure de définir clairement toutes les exigences requises et les attributs nécessaires de ces transactions, crée souvent beaucoup plus de risques de projet et de responsabilités transactionnelles que les clients apprécient ou réalisent - d’où la recommandation dans le titre ci-dessus que les clients doivent être très prudents de ce qu’ils demandent.

Pour bien gérer les risques des services de consultation « consultatifs », les clients doivent se concentrer strictement sur les dispositions contractuelles importantes ^suivantes3

1. : stipulent clairement la nature, la portée et la qualité des normes professionnelles de diligence qui doivent être exercées par le consultant;
2. stipuler des obligations et des protocoles d’assurance de la qualité pour promouvoir l’excellence du service;
3. stipuler toutes les qualifications, l’expérience, l’habilitation de sécurité, la formation et les autres attributs pertinents du personnel et des consultants applicables;
4. atténuer les transferts de personnel afin de promouvoir l’uniformité du service et la continuité des connaissances et de l’expérience du projet;
5. s’assurer qu’il y a des examens fréquents du rendement de la qualité des services, en particulier en ce qui concerne l’avancement du projet;
6. inclure des dispositions qui favorisent les communications avec les clients du consultant, y compris des stipulations liées aux décisions, aux déterminations et aux instructions du client en temps opportun au consultant; et,
7. inclure une clause de non-responsabilité expresse et le refus de toute représentation, garantie, engagement ou résultat garanti, résultat, ou que toute solution particulière sera adaptée à un usage particulier.

Pour les clients qui souhaitent gérer correctement les risques des services de conseil « livrables », ces clients doivent se concentrer sur les dispositions contractuelles suivantes:⁴

1. (c’est la règle d’or ...) moins le livrable est défini complètement, avec précision et clairement, plus le risque d’échec du projet sera grand.⁵ Si le client n’est pas en mesure de définir le livrable de manière approfondie et claire, alors ce client n’est pas (dans son propre intérêt) dans la convention de consultation livrable - bien que ce client puisse être dans une excellente position pour retenir les services d’un consultant pour fournir une assistance consultative afin d’aider à définir le livrable dont le client aura besoin pour une future transaction « livrable »;
2. fournir des jalons de développement et de livraison livrables, qui sont peut-être (mais pas toujours) liés aux seuils de paiement des frais;
3. s’assurer qu’il y a des essais d’acceptation livrables (en partie ou en totalité) fondés sur les qualités empiriques de la définition contractuelle;
4. énoncer explicitement toutes les décisions matérielles, les contributions, les déterminations et les fonctions de gouvernance du client sur lesquelles la création des produits livrables dépend et s’appuie;
5. des dispositions relatives à la gestion du changement des produits livrables doivent être incluses pour traiter les modifications demandées à la définition contractuelle de résultat garanti;
6. stipuler tous les services connexes qui sont associés à la prestation, à la mise en œuvre ou à l’utilisation du produit livrable, comme la formation, la maintenance et le soutien, l’intégration à d’autres TI ou les conseils consultatifs connexes; et,
7. même si le produit livrable doit être bien défini, il est raisonnable et habituel d’inclure des conditions préalables, des exclusions, des hypothèses et des conditions préalables dont dépend la production et la livraison du résultat défini. Cependant, comme il est indiqué ci-dessous, une telle « couverture » du rendement du service ne peut jamais remplacer une définition correcte et approfondie du résultat que le client exige du consultant qu’il promet.

Comme indiqué ci-dessus, le danger réel pour les projets de conseil informatique se posera, et les risques associés seront grandement exacerbés, lorsqu’un client (qui n’est pas en mesure de fournir toutes les spécifications empiriques, les exigences ou les spécifications pour le résultat souhaité qu’il souhaite), exige que le consultant informatique conclue une transaction livrable et (par conséquent) assume le risque d’échec de la production d’un livrable non défini. Étant donné que les risques les plus fondamentaux d’un projet livrable sont que le « produit livrable » requis ne sera pas produit, dépassera le budget convenu ou deviendra non pertinent en raison de retards dans le projet, il est absolument essentiel de définir complètement, avec précision et clairement le « livrable » en termes empiriques. À moins que cela ne soit d’abord fait, les risques du client associés à « obtenir ce qu’il a payé » (optimisation des ressources); savoir quelles décisions un client doit prendre tout au long des services; le personnel et l’expertise professionnelle requis; le prix du livrable; le temps qu’il faudra pour produire le produit livrable; et, quels changements ou compromis réalisables peuvent être nécessaires pendant la période de service, vont être au-delà de la gestion opérationnelle ou du contrôle de chaque partie.

Pour se concentrer sur l’un des exemples mentionnés ci-dessus, les services de conseil pour aider à la configuration et à la mise en œuvre de logiciels d’entreprise complexes dans une solution opérationnelle qui répondra finalement aux exigences commerciales et techniques d’un client peuvent être structurés de l’une des deux façons suivantes pour minimiser prudemment et correctement les risques liés aux projets informatiques: soit en tant que service consultatif; ou, en tant que service livrable. D’après mon expérience, les clients qui osent confondre cette distinction juridique et commerciale essentielle en essayant de pousser la cheville carrée d’un résultat ERP indéfini dans le trou rond d’une transaction livrable invitent à un risque de projet informatique exorbitant. Les tentatives des clients de s’écarter de ces structures juridiques et commerciales fondamentales en forgeant un terrain d’entente de répartition des risques en soutenant artificiellement un résultat livrable indéfini avec une litanie d’hypothèses contractuelles, de conditions préalables, d’exclusions et de qualifications à la livraison (autrement) promise de ces livrables inconnus (ou encore indéterminés) est un jeu de risque très dangereux pour le client et le consultant. Cette approche ne parvient absolument pas à aborder (sinon à ignorer) l’origine fondamentale la plus grave et la plus fondamentale du risque transactionnel dans cette circonstance - l’incapacité de définir de manière complète et claire le résultat que le client insiste pour que le consultant fournisse. Essentiellement, une telle approche disparate de la gestion des risques repose dangereusement sur la correspondance intenable et incertaine entre la couverture de performance de service délimitée du consultant (hypothèses, conditions préalables et qualifications) et la nature des attentes de résultats non satisfaites (et incertaines) du client - et moins celles-ci correspondent, plus les deux parties seront proches du centre même d’un œil de taureau de responsabilité.

Au lieu de tentatives intenables et inefficaces de gérer les risques en ignorant la cause profonde de l’échec du projet lorsque le résultat livrable n’est pas encore connu ou défini, il existe deux meilleures pratiques en développement rapide pour la gestion des risques de conseil informatique qui favoriseront grandement le succès du projet informatique d’un client:

• Tout d’abord, les clients comprennent et apprécient désormais mieux les risques (de plus en plus) évidents de la conclusion de transactions de conseil informatique dites livrables auparavant ils sont prêts à le faire, c’est-à-dire lorsqu’ils ne sont pas en mesure de définir clairement, complètement et contractuellement le résultat requis en termes empiriques – que ce soit en termes commerciaux, opérationnels, techniques ou autres. Cela signifie que plus d’efforts, de temps et de dépenses sont de plus en plus consacrés à la planification, à la préparation et à l’état de préparation de ces transactions livrables - principalement pour s’assurer que les contrats livrables (avec toute la répartition des risques et des responsabilités) peuvent être conclus.
• Deuxièmement, les consultants en informatique aident plus agressivement leurs clients à comprendre et à apprécier que de tels risques de projet profonds peuvent être grandement atténués, voire évités, en fournissant d’abord à leurs clients les conseils et l’assistance et les conseils consultatifs dont leurs clients ont besoin pour définir de manière approfondie et claire les résultats précis qu’ils recherchent, contractuellement, empiriques et commerciales (temps, termes de dépenses et d’innovation. Les clients peuvent ne pas apprécier ce qu’ils ne savent pas sur toutes les options de résultats souhaités, les possibilités ou les pièges au début d’un projet informatique, et ces services consultatifs peuvent être axés sur la définition optimale d’un projet informatique « axé sur les résultats » pour réduire considérablement le profil de risque de ces projets lorsqu’ils sont commencés.

En effet, les clients doivent faire très attention à ce qu’ils demandent et exigent de leurs consultants informatiques. Si ce sont les conseils de l’industrie et les conseils consultatifs dont ils ont besoin, alors structurer à tort ces services comme une « garantie de résultat » laissera rarement les clients informatiques satisfaits. Si le service de conseil informatique est, en fait, le mieux conçu pour fournir un résultat particulier, le client informatique doit s’assurer que ce livrable est très clairement, complètement et empiriquement défini, et soumis à toutes les protections et stipulations contractuelles abordées ci-dessus.

1. Remarques : Dans une large mesure, bon nombre des problèmes de gestion des risques cernés et discutés dans la présente mise à jour concernant les services de consultation sont communs à de nombreux autres marchés de services de TI. Cependant, par souci de clarté et d’illustration, j’ai décidé de me concentrer ici uniquement sur les accords de conseil informatique.
2. Un chirurgien doit à un patient le devoir de respecter la norme de pratique dans son domaine de spécialité. En ce qui concerne l’exemple cité ci-dessus, dans un milieu hospitalier qui exige qu’un chirurgien respecte les politiques et les procédures établies pour l’exécution de la chirurgie, comme une éponge et un nombre d’instruments à la fin de la chirurgie. Il incombe à l’hôpital d’avoir une politique en place qui établit l’exigence d’effectuer un comptage d’éponges et d’instruments avant le début et à la fin de la chirurgie abdominale. Le chirurgien a le droit, en droit, de se fier à l’avis du personnel de l’hôpital pour savoir si le décompte est correct ou incorrect. Si le personnel de l’hôpital détermine qu’il manque une éponge ou un ou plusieurs instruments (corps étranger) et en avise le chirurgien, l’obligation de diligence exige que le chirurgien prenne les mesures nécessaires pour vérifier si le corps étranger a été laissé sur place. La norme de soins exigerait que le chirurgien vérifie visuellement le champ opératoire pour déterminer s’il peut visualiser le corps étranger. Si rien n’est trouvé, on s’attendrait à ce que le chirurgien ordonne des investigations telles qu’une radiographie pour confirmer que le champ est dégagé. Une note devrait figurer dans le rapport opératoire du chirurgien ainsi qu’une note du personnel de l’hôpital sur la feuille de dénombrement indiquant que le dépouillement après l’opération ne correspondait pas au dénombrement préopératoire et quelles investigations ont été entreprises ou prévues pour déterminer que rien n’a été laissé in situ.
3. Il ne s’agit pas d’une liste exhaustive de stratégies de gestion des risques pour les services consultatifs, mais simplement d’une délimitation représentative de plusieurs approches de « pratiques exemplaires » à prendre en considération.
4. Il ne s’agit pas d’une liste exhaustive de stratégies de gestion des risques pour les services de consultation livrables, mais simplement d’une délimitation représentative de plusieurs approches de « pratiques exemplaires » à prendre en considération.
5. Cela est vrai pour de nombreuses raisons, notamment: un accord de fournisseur réduit pour les livrables en dehors de leurs capacités; une meilleure tarification; de meilleures attentes en matière de temps; des critères d’évaluation empiriques (plutôt que subjectifs); des preuves de malentendus sur les définitions; etc.
6. Les parties ne doivent pas confondre les accords de consultation consultative pour aider le client à atteindre le résultat souhaité, attendu ou prévu du client avec des contrats « livrables » - ce n’est pas le cas. Les chirurgiens et les avocats aident toujours leurs patients et leurs clients à atteindre un résultat souhaité par le patient ou le client - mais de tels services ne sont jamais fournis sur une base « livrable » lorsque le chirurgien et l’avocat conviennent d’assumer le risque du résultat patient / client, quel que soit le professionnel la qualité de leurs services.