Le fournisseur "triche", mais je ne veux pas dévoiler comment j'ai découvert

Ce que vous devez faire, c'est vérifier de manière indépendante ce que vous a dit ce jeune développeur. D'une part, vous ne savez pas si ce qu'il vous a dit est exact. Il peut y avoir eu une mauvaise communication quelque part, il peut y avoir un malentendu, il n'a peut-être pas une vue d'ensemble du point de vue technique et transmet des données incomplètes, etc. Comme on dit, “confiance, mais vérifiez.”

Pour une autre raison, vérifier ce qu'on vous a dit protège votre source. Personne n'a besoin de savoir qu'il vous a dit quoi que ce soit, car vous pouvez brandir les données comme preuve de ce qui s'est passé et omettre complètement le fait que vous avez été informé par quelqu'un. Vous n'avez pas fourni suffisamment de détails techniques pour indiquer comment vous pourriez vérifier cela, mais il ne semble pas qu'il soit difficile pour un administrateur système ou un ingénieur système décent de le faire. Bien sûr, il y a toujours la possibilité de simplement déclarer ce que votre source vous a dit, et de dire que pour éviter les représailles, vous préférez ne pas/ne pouvez pas/ne voulez pas nommer votre source. Mais la meilleure approche consiste à vous vérifier vous-même, de sorte que même le fait d'avoir une source n'ait pas d'importance.

Bien que votre préoccupation pour le programmeur junior dans ce cas soit admirable, veuillez garder à l'esprit qu'il s'agit d'une situation où votre obligation légale est envers votre client. Cela dit …

Mon client n'intenterait pas de procès, mais il se débarrasserait certainement de ce fournisseur. Nous sommes l'un de leurs plus importants clients.

Puisque votre client se débarrasserait du fournisseur et que ce dernier est malhonnête, pourquoi feriez-vous autre chose que de recommander de le faire ?

On peut dire que vous n'avez pas besoin de divulguer votre source. En fait, vous pourriez simplement dire à votre client que, puisque les prestations du prestataire n'ont pas atteint le niveau pour lequel il paie, il est temps de s'en aller. Si on vous presse, vous pouvez dire que, puisque le fournisseur de services était au courant des tests à l'avance, vous soupçonnez qu'il a alloué des ressources supplémentaires pour le test qu'il ne fournit pas normalement.

Si vous vraiment voulez protéger le programmeur junior et avoir un créneau qu'il pourrait remplir, vous pourriez l'engager vous-même, ou votre client pourrait l'engager. De cette façon, il est sûr d'éviter d'être licencié par le prestataire de services. De plus, si le prestataire de services tente de poursuivre votre client pour rupture de contrat, vous êtes sûr de l'avoir dans les parages en tant que témoin.

Un peu plus loin

D'après ce que vous savez, le fournisseur a ajouté des serveurs à la ferme pendant les tests. Si votre client a payé un montant énorme pour le benchmark, vous auriez dû espérer que l'entreprise engagée pour effectuer le benchmark l'aurait récupéré.

Le benchmark est-il supérieur à la production théorique de la ferme ? Pouvez-vous montrer que les résultats ne sont tout simplement pas réalistes ?

Pouvez-vous, d'une manière ou d'une autre, effectuer des tests de performance indépendants qui remettent en question le test de performance ?

Le fournisseur ne dispose-t-il pas d'un contrôle en temps réel des mesures de performance de base comme le processeur, les entrées/sorties, la bande passante… ? Vous auriez dû en exécuter certains pendant le benchmark divulgué. Je sais que le recul est de 20/20 mais quand même.

Vous ne cherchez pas le problème. Vous connaissez le problème et maintenant vous avez juste besoin de le prouver. Votre source vous a rendu un grand service en exposant le problème. Pouvez-vous prouver le problème sans en révéler la source ? Peut-être que vous devriez simplement vous contenter de :

Ces références ne correspondent tout simplement pas aux performances de l'application. Soit l'application est plus chargée que prévu, soit les serveurs ne sont pas aussi performants, soit il me manque simplement quelque chose. Voici des éléments à explorer… Et dans la liste des éléments à explorer, il y a un point de repère surprise.

Il est difficile de faire connaître la personne qui a fourni l'information. Il serait probablement renvoyé. Et probablement viré de façon très mauvaise dans cette difficile recherche d'un autre emploi. Je chercherais bien à trouver un moyen de révéler cette information sans exposer la personne. Personnellement, je ne les dénoncerai pas. Sans une vérification indépendante, il est peu probable que cela ne tienne pas la route de toute façon.

Si la performance dans la vie réelle ne correspond pas à la performance pendant le test (et vous avez les données pour le prouver), la solution devrait être facile : informez le fournisseur, et si la performance ne s'améliore pas, annulez le contrat.

Vous n'avez pas à dire comment vous avez trouvé que le test était truqué, seulement que la performance quotidienne ne correspond pas au benchmark du test (vous pouvez même demander “innocemment” : est-ce que la configuration du matériel/logiciel a changé depuis le benchmark ?) Mais vos avocats pourraient être intéressés de parler à la société que vous avez payée pour le coûteux test de référence - était-elle la même que le fournisseur de services, ou différente ?

Concernant votre fuite : Ne révélez pas son nom, ce serait le jeter sous un bus sans raison valable et sans avantage pour votre propre entreprise. Mais vous pouvez rester en contact et éventuellement lui rendre la pareille : avertissez-le de la nécessité de chercher un autre emploi avant l'accident (lorsque l'annulation du contrat est une information publique, pas avant). Je comprends le dilemme suivant : vous ne pouvez pas lui fournir de bonnes références (ou peut-être le pouvez-vous - en lui disant qu'il vous a été utile et qu'il ferait un effort supplémentaire pour communiquer avec le client). La façon la plus simple de lui rendre la pareille serait de **l'emmener prendre un café un jour (en dehors des locaux des deux entreprises, et lui dire que la réunion est strictement confidentielle ). Cela pourrait être peu de temps après que l'annulation du projet ait été rendue publique, pas avant, et expliquez-lui dans quel genre de politique d'entreprise il s'est empêtré, et quel dilemme éthique compliqué il est libre de prendre (pour vous deux). Ainsi, il sera mieux à même de faire face à la situation la prochaine fois. Il semble être un homme honnête et serviable, peut-être pas encore au courant des subtilités de la vie - et vous avez une excellente occasion de l'aider à le comprendre ; aidez-le à apprendre la leçon sans nuire à sa carrière.

Je ne sais pas comment il réagira la prochaine fois : ne pas vous le dire ou ne pas tromper les clients ? :-)

Les autres réponses sont vraiment bonnes, mais je n'ai pas vu cela explicitement indiqué dans aucune d'entre elles -

Pourquoi votre recommandation ne serait-elle pas simplement que leur fournisseur externe de benchmarking effectue un autre test car leur méthode de test était défectueuse. Si vous savez que l'information a été publiée et que les services ont été désactivés, je suis sûr que vous pouvez trouver une norme NIST ou ISO indiquant la procédure à suivre pour ce type de test. Vous pourriez même chercher des informations sur les meilleures pratiques auprès de l'ISACA.

Peu importe ce que vous savez, juste qu'en publiant l'heure et l'environnement modifié, ce n'est pas un test valable. Même dans ce cas, je pourrais aller voir l'entreprise externe de test et lui demander ce qu'elle en pense.

Il semble que l'entreprise de test et le fournisseur aient tous deux participé à la création d'une situation pour des résultats inexacts et que IMO ait été au moins négligeant et au plus * collusoire **.

Encore une fois, je ne sais pas pour quel emploi vous avez été embauché, mais si l'un de ces aspects est couvert, c'est un bon moyen d'éviter de divulguer des informations confidentielles.

Divulguez tout à votre client et parlez-lui des informations dont vous disposez. Vous avez l'obligation professionnelle de lui fournir le meilleur service possible et vous n'avez aucune obligation professionnelle envers le développeur junior du centre de données. Votre client vous a littéralement payé pour découvrir de telles choses.

Après avoir divulgué les informations que vous avez acquises (pour lesquelles votre client vous paie). Discutez de la possibilité de vérifier ce que le développeur junior a dit.

Si c'est le cas, travaillez certainement avec un autre fournisseur.

En tant que personnes, nous essayons d'être gentils et justes et c'est admirable. En tant que professionnel, vous avez l'obligation de fournir le meilleur service possible à votre client.

Le simple fait que l'application réelle ait des “performances logicielles horribles”, alors que dans les tests, “les résultats étaient bons” devrait sonner l'alarme pour tout le monde et peut être utilisé comme point de départ pour la discussion, ou pour contester les tests. Vous pourriez/devriez éveiller les soupçons du client sur cette divergence, surtout si l'on considère que vous en êtes “responsable”.

De plus, le problème initial reste non résolu et peut être analysé plus en détail, avec ou sans l'intervention de la société externe grassement payée. Des outils sont disponibles pour de nombreuses technologies afin de contrôler les performances de production sans vraiment les affecter ; vous pourriez vouloir utiliser cela pour quantifier “l'horrible”. En ajoutant à la réponse de HopelessN00b , ce serait une autre façon de vérifier.

Votre source est un “développeur junior employé par l'hôte du serveur, qui a bavardé à ce sujet”. En d'autres termes, en ce qui vous concerne, vous n'avez absolument rien fait de mal pour obtenir cette information.

Votre devoir n'est pas envers le FAI, ou le développeur junior du FAI, mais envers votre client. Je pense donc que vous devez informer votre client. Vous pouvez mentionner le type de source que vous avez sans mentionner la source réelle. Ce qui se passera : Votre client cessera d'utiliser un PSI qui triche, le PSI perdra le client qu'il triche, et le développeur junior ne parlera plus, espérons-le, de cette situation, car il sera en danger.