Summary

  • Dudobi reunit conseil, architecture, migration, securisation, supervision, administration, reprise et optimisation des couts autour d'AWS. Cette largeur peut alleger la coordination interne, mais elle concentre aussi chez le prestataire une part importante du contexte technique et du pouvoir d'action.
  • Les informations publiques confirment une presence de contact a Londres et en Afrique du Sud, une direction nommee, un catalogue etendu, des inscriptions dans l'ecosysteme AWS et un cas de migration detaille par Dudobi. Elles ne demontrent ni la capacite disponible pour chaque mission, ni des resultats universels, ni une performance independamment mesuree.
  • Un client prudent garde la maitrise des comptes, des identites, des journaux, des donnees de cout, des choix de region et des preuves d'exploitation. Il exige aussi des responsabilites testables, une documentation reutilisable et un plan de sortie executable avant que le service gere ne devienne indispensable.

Read the Dudobi Limited directory profile.

La photographie associee a cet article montre un centre de donnees reel sous licence CC BY-SA, uniquement comme illustration generique du cloud gere. Elle ne represente aucun site de Dudobi, d'un client ou d'AWS.

Une promesse de simplicite qui redistribue la complexite

La proposition affichee sur https://dudobi.com/ part d'un constat familier aux directions techniques: AWS offre une grande souplesse, mais cette souplesse multiplie les arbitrages. Identites, reseaux, sauvegardes, observabilite, chiffrement, capacite, engagements de depense et plans de reprise doivent rester coherents alors que les applications evoluent. Dudobi place la securite, l'optimisation et la disponibilite au centre de son discours et propose de prendre en charge une partie de cette charge operationnelle. Pour une entreprise en croissance, acheter une attention specialisee peut etre plus realiste que recruter immediatement tous les profils necessaires.

La valeur d'un tel service ne reside pas seulement dans la connaissance de produits AWS. Elle tient a la continuite: surveiller les alertes, maintenir des procedures, traiter les changements et reconnaitre des signaux faibles au fil des mois. Une equipe externe qui rencontre plusieurs architectures peut aussi apporter des comparaisons et des habitudes qu'une petite equipe interne n'a pas encore acquises. Le gain potentiel est donc organisationnel autant que technique.

Mais la complexite ne disparait pas. Elle change de lieu. Une partie se retrouve dans les procedures de Dudobi, une autre dans les services AWS choisis, une autre encore dans les interfaces entre le client et le prestataire. Si ces interfaces restent implicites, la simplicite ressentie au quotidien peut masquer une dependance croissante. Le probleme apparait alors lors d'un incident, d'un desaccord sur un changement, du depart d'une personne cle ou de la fin du contrat.

Une direction qui envisage Dudobi devrait ainsi reformuler la promesse commerciale en questions de controle. Quelles taches seront effectivement retirees aux equipes internes ? Quelles decisions Dudobi pourra-t-elle prendre seule ? Quelles preuves seront remises apres une action sensible ? Qui supportera l'impact commercial d'une indisponibilite ou d'une mauvaise configuration ? Externaliser l'execution peut etre rationnel; externaliser la comprehension de ce qui est execute l'est beaucoup moins.

Ce que le dossier public permet d'etablir

La page de presentation de l'entreprise, https://dudobi.com/about-us/, identifie des responsables pour le developpement commercial, les services geres, les services professionnels et les operations. Elle mentionne des experiences en administration de systemes, reseaux, securite, technologies Microsoft, cloud prive, Azure et conception cloud. Elle publie egalement des coordonnees a Londres et en Afrique du Sud. Ces elements dessinent une societe de services animee par des responsables nommes, et non un simple produit logiciel sans equipe visible.

Ils ne permettent toutefois pas de deduire la taille actuelle des effectifs, leur disponibilite pour une mission donnee, l'organisation des astreintes ou la profondeur de chaque specialite. Une biographie professionnelle renseigne sur un parcours, pas sur la capacite mobilisable a une date precise. De meme, deux lieux de contact n'indiquent pas ou se deroulent chaque intervention, chaque acces de support ou chaque traitement de donnees.

L'ecosysteme externe ajoute des points de reperage. AWS publie une fiche Dudobi dans son annuaire de partenaires, a l'adresse https://partners.amazonaws.com/partners/0010h00001jDXbrAAG/, ainsi qu'un profil vendeur sur AWS Marketplace, https://aws.amazon.com/marketplace/seller-profile?id=seller-d4sj47qcaygdc. RIPE NCC inscrit aussi Dudobi Limited parmi les registres proposant des services au Royaume-Uni sur https://www.ripe.net/membership/member-support/list-of-members/gb/. Ces presences consolident l'identite et le contexte commercial ou reseau de l'entreprise.

Elles ne constituent pas une garantie de resultat. Une fiche partenaire ne transfere pas a Dudobi les engagements de service d'AWS. Un profil de place de marche ne certifie ni la qualite d'une migration ni la solidite d'une organisation d'astreinte. Une inscription chez RIPE NCC apporte un contexte pertinent pour les activites reseau, mais ne mesure pas la qualite d'un service cloud gere. Ces distinctions sont importantes parce que l'accumulation de logos et d'annuaires peut donner une impression d'assurance plus forte que la preuve disponible.

Le dossier public fournit donc un point de depart serieux pour la diligence, pas sa conclusion. Les references clients, les qualifications de l'equipe affectee, les exemples de rapports, les controles d'acces et les conditions contractuelles doivent completer ce tableau. Le niveau d'examen devrait dependre de la criticite de la charge: un site de communication et un systeme de transaction reglemente n'exigent ni les memes garanties ni la meme profondeur de verification.

Un catalogue large exige une frontiere de service precise

La page https://dudobi.com/solutions/ rassemble des revues Well-Architected, des evaluations d'optimisation et de licences, des feuilles de route, du durcissement de securite, de la planification de capacite, des migrations, de la modernisation d'applications et de bases de donnees, Kubernetes, de la supervision, de l'administration systeme, des operations reseau, de la reprise apres sinistre et du travail sur les couts. Cette amplitude peut seduire un client qui cherche un interlocuteur unique plutot qu'une mosaique de consultants.

Un catalogue n'indique pourtant pas quelles prestations seront incluses dans un contrat particulier, avec quels outils, quelles heures de couverture ou quelle equipe. Le mot « supervision » peut signifier la collecte d'indicateurs techniques, l'analyse permanente d'alertes ou une prise en charge complete jusqu'au retablissement. La « securite » peut designer une evaluation ponctuelle, l'application de configurations de reference, une surveillance continue ou seulement des recommandations. Sans definition operationnelle, deux parties peuvent croire avoir achete et vendu des choses differentes.

Le bon document d'achat n'est donc pas une reprise de la brochure, mais une conception de service. Il enumere les comptes et environnements couverts, les actions autorisees, les exclusions, les plages horaires, les outils, les responsables, les preuves attendues et les criteres d'acceptation. Il precise aussi ce qui reste au client: code applicatif, classification des donnees, arbitrages de risque, validation des changements majeurs et communication aux utilisateurs.

Cette precision sert les deux parties. Elle evite au client de supposer que toute difficulte liee au cloud appartient desormais a Dudobi. Elle evite aussi au prestataire d'etre tenu pour responsable d'un resultat qu'il ne controle pas, par exemple une erreur dans le code metier ou une decision de produit. Lorsque le perimetre s'etend, le document doit evoluer; sinon la dependance reelle grossit tandis que le contrat reste fige.

Du conseil ponctuel a l'autorite operationnelle durable

Dudobi distingue les services professionnels exposes sur https://dudobi.com/professional-services/ et les services geres presentes sur https://dudobi.com/managed-services-2/. Les premiers couvrent notamment l'evaluation, l'architecture, la migration et la modernisation. Les seconds prolongent la relation dans l'exploitation courante. Cette distinction est fondamentale: un projet concentre temporairement le savoir, alors qu'un service gere accumule, jour apres jour, une memoire de l'environnement et des droits d'intervention.

Pendant une migration, l'equipe externe apprend les dependances historiques, les contraintes reseau, les habitudes d'exploitation et les exceptions de securite. Si cette connaissance demeure dans les conversations ou dans des documents prives du prestataire, le client peut recevoir une plateforme fonctionnelle tout en perdant la capacite de l'expliquer. Les livrables devraient inclure des decisions d'architecture, des inventaires, des cartes de dependances, des resultats de test, des risques non resolus, des procedures de retour arriere et des definitions d'infrastructure placees dans des espaces controles par le client.

Dans la phase geree, les tickets et les alertes donnent a Dudobi une connaissance encore plus fine: quels changements sont dangereux, quelles solutions provisoires sont devenues permanentes, quels signaux annoncent un incident et quels interlocuteurs peuvent trancher. Cette connaissance produit de la valeur. Elle produit aussi un avantage difficile a remplacer si elle n'est pas regulierement structuree et partagee.

La gouvernance doit donc suivre l'evolution de la relation. Au debut, elle verifie les livrables d'un projet. Ensuite, elle examine la qualite des changements, la recurrence des incidents, l'etat des procedures et le transfert de competence. Le but n'est pas d'obliger le client a refaire le travail de Dudobi, mais de lui permettre de comprendre, contester ou reprendre les operations sans repartir de zero.

Transformer les promesses commerciales en mesures discutables

La page consacree a la pratique AWS, https://dudobi.com/aws-practice/, publie des chiffres relatifs aux transformations, a la disponibilite, aux reductions de cout et aux migrations. Ces donnees sont presentees par le fournisseur lui-meme. Elles peuvent signaler une experience et donner des sujets de discussion, mais la documentation publique ne fournit pas une methode independante permettant de les appliquer a une future charge de travail.

L'acheteur devrait convertir chaque promesse en definition. La disponibilite de quoi, mesuree depuis ou, pendant quelle periode et avec quelles exclusions ? Une reduction de cout par rapport a quel mois de reference, pour le meme niveau de demande et apres quelles concessions sur la capacite ou la resilience ? Une migration sans interruption visible inclut-elle toutes les fonctions, la reconciliation des donnees et la periode suivant la bascule ? Sans ce travail, un chiffre precis peut reposer sur une notion floue.

Les objectifs doivent aussi distinguer ce que Dudobi controle de ce qui depend du client, d'AWS ou d'un autre fournisseur. Une panne applicative n'a pas la meme cause qu'une erreur d'infrastructure; une economie obtenue par une baisse d'activite n'est pas une optimisation technique. La mesure devient utile lorsqu'elle aide a attribuer une cause et a decider d'une action, pas lorsqu'elle sert uniquement de note globale.

Cette approche n'est pas hostile au prestataire. Au contraire, elle protege Dudobi contre des attentes illimitees et donne au client une base pour reconnaitre un bon travail. Un objectif credible associe une definition, une source de donnees accessible, une frequence, un proprietaire et une procedure lorsque le resultat derive. Il peut alors soutenir une conversation de gestion plutot qu'une dispute retrospective.

La responsabilite partagee compte desormais trois centres de decision

Dans un montage cloud gere, AWS exploite ses services, Dudobi peut concevoir et administrer une partie de l'environnement, et le client conserve l'application, les donnees, les obligations legales et les consequences commerciales. D'autres acteurs peuvent s'ajouter: fournisseur d'identite, editeur de logiciel, operateur de connectivite ou outil de securite. La formule generale de responsabilite partagee ne suffit plus; il faut decrire les gestes concrets.

Qui cree les comptes et controle les identifiants racine ? Qui approuve l'usage d'une nouvelle region ? Qui peut modifier une politique d'identite, isoler une charge, interrompre un service ou declencher une restauration ? Qui classe une alerte comme incident de securite et qui previent les personnes concernees ? Une simple colonne indiquant « partage » ne repond pas a ces questions au moment ou chaque minute compte.

La capacite technique doit etre separee de l'autorisation. Dudobi peut avoir les droits necessaires pour changer une regle reseau sans pour autant etre autorisee a le faire dans toutes les circonstances. Les operations frequentes et reversibles peuvent suivre des procedures preapprouvees. Les actions a fort impact exigent une validation plus forte. Les pouvoirs d'urgence doivent avoir des declencheurs etroits, etre journalises et faire l'objet d'un examen rapide apres usage.

La securite depend enfin de preuves que le client peut conserver. Les journaux d'identite, de configuration et de reseau, les alertes, les vulnerabilites et les decisions d'acceptation du risque devraient aboutir dans un environnement auquel le client garde un acces direct. Des identites nominatives, des droits limites dans le temps, une revue periodique des privileges et une alerte sur les acces d'urgence rendent la delegation observable. La surveillance peut etre operee par Dudobi sans que l'historique devienne sa propriete exclusive.

Les couts ne se reduisent pas a une chasse au gaspillage

L'optimisation financiere fait partie du positionnement de Dudobi. Elle repond a une difficulte reelle: une facture AWS combine la demande des applications, les transferts de donnees, les options de support, les produits achetes sur une place de marche, les ressources oubliees et les engagements a long terme. Un specialiste peut reperer des anomalies, ajuster des capacites et rendre les arbitrages plus lisibles.

Une economie n'a toutefois de sens qu'avec une base comparable. Il faut separer les activites exceptionnelles de migration, l'evolution du trafic, les changements de prix et les modifications d'architecture. Reduire une ressource peut faire baisser la facture tout en augmentant la latence ou le travail des equipes. Souscrire un engagement peut diminuer le prix unitaire tout en limitant la flexibilite. La bonne question n'est pas « combien avons-nous economise ? », mais « quelle valeur et quel risque avons-nous achetes pour ce cout ? ».

Le client devrait conserver un acces direct aux donnees de facturation, aux etiquettes d'allocation, aux budgets et aux alertes d'anomalie. Dudobi peut construire des tableaux de bord et recommander des actions, mais la finance et l'ingenierie internes doivent pouvoir reproduire le raisonnement. Une facture qui ne devient comprehensible qu'apres l'intervention du prestataire est elle-meme un indice de dependance.

Les honoraires du service gere merient la meme transparence. Forfait recurrent, travaux de projet, extensions de perimetre et interventions hors horaires doivent etre distinguables. Les incitations ne devraient pas recompenser une reduction aveugle des depenses d'infrastructure. Le cout minimal n'est pas toujours compatible avec les objectifs de reprise, la securite ou la liberte de changer d'architecture.

La disponibilite part de l'usage, pas d'un voyant vert

Le terme « disponibilite » peut decrire un serveur, un service AWS, une application ou la capacite d'un client a achever une operation. Ces niveaux ne coincident pas toujours. Une infrastructure peut sembler saine tandis qu'une authentification echoue, qu'un message reste bloque ou que des donnees sont incoherentes. Les objectifs devraient donc partir du service rendu a l'utilisateur, puis relier cette experience aux composants techniques.

Dudobi publie un modele de priorites de service sur https://dudobi.com/service-priority-levels/. L'existence d'un vocabulaire commun est utile, mais elle ne prouve ni les delais obtenus dans un contrat donne ni les performances passees. Pour devenir exploitable, chaque priorite doit correspondre a des effets observables: nombre d'utilisateurs touches, perte d'une fonction critique, exposition de securite, risque pour l'integrite des donnees, contrainte reglementaire et existence d'une solution de contournement.

La prise en compte d'un ticket n'est pas le retablissement. Un accord solide distingue l'accuse de reception, la mobilisation d'une personne qualifiee, la frequence des informations, le contournement, la restauration et l'analyse finale. La dependance a AWS ou a un autre editeur ne doit pas interrompre la communication avec le client. Dudobi peut coordonner l'escalade externe tout en gardant une responsabilite claire sur l'information et les actions qui relevent de son perimetre.

Les tests donnent davantage de confiance que les diagrammes. Restaurer une sauvegarde, perdre un acces administratif, simuler l'indisponibilite d'une dependance ou verifier un plan de bascule revele les autorisations manquantes et les instructions obsoletes. Les resultats doivent avoir des responsables et des echeances. La resilience n'est pas un attribut achete une fois; c'est une capacite qui se degrade si elle n'est pas entretenue.

Un cas de migration concret, mais non generalisable

Dudobi rassemble des recits de projets sur https://dudobi.com/success-stories/. Comme toute selection realisee par un fournisseur, cette bibliotheque montre des exemples choisis et non un echantillon representatif de l'ensemble des missions. Elle reste utile pour comprendre le type de problemes rencontres et preparer des questions, a condition de distinguer mecanismes techniques et formules de succes.

Le cas d'une plateforme de communications, https://dudobi.com/success-stories/cloud-communications-platform/, est le plus tangible dans les informations disponibles. Le client n'est pas nomme. Dudobi decrit six etapes: analyse, conception et construction, pilote, migration, gestion puis modernisation. L'architecture cite plusieurs services AWS de reseau, calcul, stockage, base de donnees, sauvegarde et supervision, notamment une repartition sur plusieurs zones de disponibilite.

Ce recit illustre la capacite revendiquee de Dudobi a suivre un projet de l'etude jusqu'a l'exploitation. Il montre aussi qu'un depart de serveurs physiques ne supprime pas la dependance technique: il la repartit entre davantage de services logiciels, chacun avec ses couts, ses limites et ses modes de panne. Une architecture peut gagner en resilience tout en devenant plus exigeante a comprendre et a gouverner.

Les resultats et la faible interruption rapportes sont des affirmations de Dudobi concernant un cas non identifie. Ils ne doivent pas devenir la prevision automatique d'une autre migration. Un acheteur peut demander le volume de donnees, la duree, les objectifs de reprise, le dispositif de test, les incidents apres bascule et le partage du travail avec l'equipe du client. Il peut aussi chercher une reference dont la taille, la regulation et le type d'application ressemblent aux siens.

La lecon la plus robuste concerne la methode: un pilote et des criteres d'arret explicites reduisent le risque d'une bascule. Les donnees doivent etre reconciliees, les ecarts de securite suivis et le retour arriere pense avec les ecritures produites apres le changement. Moderniser l'application en meme temps que la relocaliser peut etre justifie, mais augmente les variables. Le choix doit appartenir a la gouvernance du client, eclairee par l'expertise de Dudobi.

L'expérience multicloud ne garantit pas la portabilité

La présentation des dirigeants évoque, en plus d'AWS, une expérience de l'infrastructure privée et de Microsoft Azure. Pour une organisation dont les applications traversent plusieurs environnements, cette largeur peut être utile. Les incidents réels suivent rarement la frontière commerciale d'une plateforme: une identité gérée ailleurs, une liaison réseau, un logiciel historique ou un service sur site peut interrompre une chaîne pourtant saine dans AWS. Un prestataire capable de regarder au-delà d'un seul fournisseur peut mieux repérer ces dépendances.

Il serait néanmoins imprudent d'en déduire une neutralité automatique entre clouds. Une machine virtuelle peut sembler transférable, tandis qu'une base de données administrée, une politique d'identité, une file d'événements ou une chaîne de déploiement peut demander une reconception complète. Les services natifs offrent souvent un bénéfice supérieur précisément parce qu'ils s'intègrent étroitement à leur plateforme. Le verrouillage n'est pas toujours une erreur économique; il devient un risque lorsque son coût, son délai et ses conséquences n'ont jamais été évalués.

Le périmètre proposé par Dudobi devrait donc indiquer quelles compétences et quels outils s'appliquent à chaque environnement. Le client peut demander qui coordonne un incident qui traverse AWS, Azure et un réseau privé, comment les journaux sont rapprochés et quel fournisseur porte l'escalade. Une vue d'ensemble ne doit pas dépendre d'un tableau de bord propriétaire auquel seul le prestataire accède. Une cartographie contrôlée par le client reste nécessaire pour distinguer une panne locale d'une rupture entre systèmes.

La portabilité mérite enfin des choix explicites. Pour chaque service fortement spécifique à AWS, une décision d'architecture peut noter le bénéfice attendu, les alternatives et l'effort approximatif d'une sortie. Il ne s'agit pas de construire en permanence pour un déménagement hypothétique, ce qui coûterait cher et pourrait dégrader le produit. Il s'agit de savoir où l'entreprise accepte une dépendance et de ne pas la découvrir lorsque le changement devient urgent.

Le service quotidien doit produire du savoir partageable

Un centre de services voit passer demandes, alertes, changements et incidents. Cette matière permet de comprendre l'environnement mieux qu'un audit ponctuel. Elle peut aussi enfermer le contexte dans une suite de tickets si aucun travail de capitalisation n'est prévu. Le volume clôturé ne dit pas si une faiblesse a été supprimée, si une solution provisoire est devenue permanente ou si la même panne revient sous des intitulés différents.

Les rapports devraient donc relier l'activité à l'amélioration du système. Une répétition appelle une analyse de cause; une exception durable appelle une décision de risque; une opération manuelle fréquente appelle une automatisation ou une justification. Les procédures importantes devraient préciser les prérequis, les droits nécessaires, le contrôle avant action, le retour arrière et la preuve à conserver. Dudobi peut maintenir ces documents, mais le client doit pouvoir les consulter et les réutiliser.

La qualité d'une remise de service se mesure également à la capacité d'un tiers compétent à comprendre ce qui s'est passé. Un ticket utile indique le symptôme, le diagnostic, l'action, l'autorisation, l'effet observé et les suites. Cette discipline facilite les audits, réduit la dépendance à la mémoire d'une personne et améliore les transitions internes chez Dudobi comme chez le client. Elle rend aussi les désaccords plus factuels: on peut examiner une décision plutôt que reconstruire des souvenirs contradictoires.

Enfin, le service doit prévoir un lieu pour arbitrer les tensions ordinaires. Une équipe produit peut privilégier la vitesse, la sécurité demander un contrôle supplémentaire et Dudobi signaler un risque d'exploitation. Sans instance claire, la demande la plus urgente devient la politique de fait. Avec des objectifs et un appétit pour le risque documentés, le prestataire peut agir rapidement tout en laissant au client la décision qui lui appartient.

La souverainete des donnees ne se lit pas sur une adresse

Les coordonnees publiees a Londres et en Afrique du Sud ne determinent pas l'emplacement de chaque charge, sauvegarde, journal ou session d'assistance. De la meme facon, choisir une region AWS ne suffit pas a decrire tous les mouvements de donnees. La localisation est une propriete de l'architecture et de l'exploitation, pas celle du siege du prestataire ou du client.

L'inventaire devrait couvrir le stockage principal, les repliques, les sauvegardes, les copies de reprise, les journaux de supervision, les pieces jointes aux tickets et les donnees administratives. Un membre de l'equipe peut consulter des informations depuis un autre pays sans que la charge principale quitte sa region. Des outils tiers peuvent creer leurs propres transferts. Dire qu'un service est heberge au Royaume-Uni reste incomplet si ces chemins secondaires ne sont pas documentes.

Les choix de region peuvent etre appliques par des politiques de compte, des definitions d'infrastructure et des alertes. Les exceptions devraient avoir un motif, une approbation et une date de fin. Le chiffrement reduit certains risques, mais ne tranche pas toutes les questions de juridiction: l'emplacement des cles, les metadonnees et les droits d'assistance comptent aussi. Le conseil juridique n'est utile que s'il s'appuie sur le dessin technique reel.

La presence operationnelle dans deux pays invite donc a poser des questions, sans autoriser de conclusion sur des traitements non publies. Qui peut acceder a quelles donnees, depuis quel pays et dans quel but ? Quels sous-traitants interviennent ? Quelles notifications accompagnent un changement de lieu ou d'outil ? Les reponses doivent venir du contrat et de l'architecture du client, non d'une supposition tiree d'une page de contact.

La localite rejoint enfin la resilience et la sortie. Une sauvegarde placee sous la meme autorite de compte ou soumise au meme risque juridique ne procure pas necessairement l'independance attendue. Exporter des volumes importants prend du temps et peut engendrer des frais. Formats, delais, bande passante, retention et effacement apres resiliation doivent etre prevus pendant que la relation fonctionne bien.

Gouverner a plusieurs vitesses sans perdre la trace des decisions

Toutes les operations cloud ne meritent pas la meme procedure. Une tache courante, reversible et bien comprise peut etre preautorisee dans une instruction. Un changement ayant un impact client exige une revue, un test et une possibilite de retour. Une nouvelle region, un engagement financier important ou le remplacement d'une base de donnees appelle une decision qui associe technique, risque et metier.

Dudobi peut executer rapidement les gestes repetitifs, a condition que la delegation soit bornee. Les preuves doivent etre proportionnees: enregistrement automatique pour une operation standard, justification et validation pour une regle reseau, dossier d'architecture et criteres d'acceptation pour une migration. Une gouvernance uniforme produit soit trop de bureaucratie, soit trop peu de controle sur les choix importants.

Le client a besoin d'un responsable de service interne capable de dialoguer avec Dudobi. Cette personne ne doit pas reproduire toutes les competences du prestataire, mais comprendre les objectifs, les risques, les couts et la qualite des preuves. Sans interlocuteur informe, l'externalisation peut affaiblir la decision: les equipes internes ne savent plus contester une recommandation et la direction n'entend qu'une synthese commerciale.

Des reunions regulieres devraient examiner les tendances: incidents repetes, echecs de changement, exceptions anciennes, acces privilegies, tests de restauration, derives de cout et evolutions prevues d'AWS. Un rythme plus strategique peut traiter l'architecture, les engagements financiers, le contrat et la capacite de sortie. La gouvernance devient alors une activite ordinaire, et non une reunion improvisee lorsqu'une crise rend soudain le controle urgent.

Mesurer la qualite de la dependance, pas son absence

Un service gere cree necessairement une dependance. La question utile est de savoir si elle reste proportionnee, observable et reversible. Les indicateurs operationnels peuvent suivre la disponibilite du service metier, la recurrence des incidents, le taux d'echec des changements, le temps de restauration, la reussite des tests de sauvegarde, l'anciennete des risques de securite et les ecarts de depense.

Les indicateurs de capacite sont tout aussi revelateurs. Le client possede-t-il des diagrammes et des procedures a jour ? Ses equipes peuvent-elles acceder directement aux journaux et aux donnees de facturation ? Combien d'actions critiques dependent d'une seule personne chez Dudobi ? Les definitions d'infrastructure sont-elles completes et executables ? Combien de temps faudrait-il a une autre equipe competente pour reprendre l'exploitation ?

Un indicateur isole peut tromper. Moins de tickets peut signifier une meilleure stabilite ou une reticence a signaler les problemes. Une cloture rapide peut cacher des reouvertures. Une baisse de cout peut provenir d'une baisse d'activite. Il faut croiser tendances, echantillons de dossiers et exercices. La mesure doit susciter de meilleures questions, pas fabriquer un score unique qui dispense de lire les faits.

Le reporting commercial devrait separer les frais AWS, les produits de place de marche, les honoraires recurrents de Dudobi et les projets. Le reporting de securite devrait mettre en evidence les risques acceptes et les actions en retard, pas seulement le volume d'alertes. Cette lisibilite aide les deux parties a savoir si le service renforce progressivement le client ou concentre toujours davantage le savoir chez le prestataire.

Le contrat doit suivre la realite de l'exploitation

Un contrat de cloud gere est utile lorsqu'il decrit le service effectivement rendu. Le perimetre devrait nommer les comptes, charges, environnements, lieux et horaires. La matrice de responsabilite doit descendre jusqu'aux actions. Les clauses de securite doivent couvrir les acces, les journaux, la notification d'incident, les sous-traitants, l'effacement et la remise de preuves. Les clauses sur les donnees doivent correspondre aux mouvements reels.

Les niveaux de service structurent l'attention, l'escalade et l'amelioration plus qu'ils ne compensent une perte grave. Un avoir financier suffit rarement apres une longue indisponibilite. Des manquements repetes devraient declencher un plan correctif, puis une assistance a la transition si la situation perdure. Un changement materiel d'outil, de lieu de prestation ou de sous-traitant doit entrainer une information et une reevaluation du risque.

La propriete intellectuelle merite une distinction nette. Dudobi peut legitimement conserver ses methodes reutilisables, mais les configurations, schemas, decisions, procedures et historiques propres au client doivent rester exploitables par celui-ci. Les droits d'audit peuvent s'appuyer sur des rapports et des echantillons cibles plutot que sur une intrusion illimitee. Les obligations du client, notamment les decisions rapides et la maintenance applicative, doivent aussi etre explicites.

Aucun texte n'anticipe tous les evenements techniques. Il faut donc inscrire le mecanisme de gouvernance dans l'accord: responsables nommes, cadence, trace des decisions, escalade et controle des changements. Lorsque les pratiques s'eloignent des documents, les parties devraient corriger les documents plutot que compter sur la memoire de quelques individus.

Preparer la sortie avant d'avoir envie de partir

Un plan de sortie n'exprime pas une defiance particuliere envers Dudobi. Il protege la continuite face a une acquisition, un changement de strategie, une evolution d'equipe chez le prestataire ou une reinternalisation. Le meilleur moment pour convenir des actifs, des formats et de l'assistance est le debut de la relation, lorsque la cooperation est bonne et que les informations sont accessibles.

Les actifs essentiels comprennent le controle des comptes, l'administration des identites, les schemas d'architecture, les definitions d'infrastructure, les depots de code, les procedures, la configuration de supervision, les tickets, l'historique des incidents, les donnees de cout, les constats de securite et les contacts. Pour chacun, le client devrait connaitre le format d'export, la frequence de mise a jour et la duree de conservation.

Si les comptes cloud appartiennent deja au client, une sortie n'exige pas forcement de deplacer les charges. Il faut toutefois remplacer les acces, les outils controles par Dudobi, certaines licences et les habitudes operationnelles. L'assistance a la transition doit avoir un perimetre, des tarifs, une disponibilite et un calendrier. Les privileges doivent etre reduits par etapes puis verifies apres revocation.

Une repetition rend le plan credible. Faire suivre une procedure par une autre personne, restaurer des donnees dans un compte distinct ou exporter un historique de tickets revele les lacunes sans resilier le contrat. La reversibilite n'est pas l'absence d'engagement; c'est la capacite a changer de choix sans perdre la maitrise du systeme ni les preuves necessaires a son exploitation.

Une diligence proportionnee a la charge confiee

Les informations publiques ne donnent pas le chiffre d'affaires de Dudobi, sa capacite totale en personnel, sa concentration de clientele, sa chaine complete de sous-traitance ou sa resilience financiere. Elles n'offrent pas de mesure independante des chiffres avances sur la pratique AWS. Elles ne montrent ni les contrats, ni l'architecture privee de clients, ni la performance reelle des temps de reponse, ni d'eventuels incidents. Ces absences ne sont pas des accusations; elles delimitent ce qu'un acheteur doit verifier autrement.

Une diligence efficace commence par le client. Celui-ci inventorie les services metier qui dependent d'AWS, l'impact de leur indisponibilite, les comptes, les donnees, les regions, les competences actuelles, les faiblesses connues et les couts. Dudobi peut alors proposer une conception de service liee a des besoins reels plutot qu'un ensemble generique. La criticite determine la profondeur des controles.

L'etape suivante consiste a rencontrer l'equipe susceptible d'intervenir, examiner des exemples de procedures et de rapports, tester la conception des acces et demander des references comparables. Un pilote limite peut verifier la qualite de la communication, la remise des preuves et la capacite a travailler avec les equipes internes. Les promesses de securite, d'optimisation et de disponibilite deviennent des criteres mesurables avant l'extension du perimetre.

Avant de confier davantage d'operations, le client fixe la propriete des comptes, journaux, codes, documents et donnees financieres. Il cartographie les acces et les mouvements de donnees par pays, planifie des tests de reprise et de sortie, puis confronte le contrat au dessin technique. Cette sequence transforme une decision d'achat en dispositif de controle continu.

Dudobi peut apporter une valeur reelle justement parce que la complexite d'AWS est reelle. Le choix mature n'est ni de refuser toute delegation, ni de confondre delegation et abandon. Le service gere remplit sa promesse lorsque l'attention specialisee rend l'organisation cliente plus resiliente et mieux informee. Il devient fragile lorsque la commodite rend opaques les acces, les preuves, les couts et les options de l'entreprise qui continue pourtant d'en assumer les consequences.

Sources consultees

La presentation generale et le positionnement de Dudobi sont exposes sur https://dudobi.com/. Les informations relatives aux responsables et aux lieux de contact proviennent de https://dudobi.com/about-us/. Le catalogue de services est publie sur https://dudobi.com/solutions/, tandis que la pratique AWS et ses chiffres commerciaux figurent sur https://dudobi.com/aws-practice/. Les pages https://dudobi.com/professional-services/ et https://dudobi.com/managed-services-2/ decrivent respectivement les interventions de projet et l'exploitation continue.

Le modele de priorites est disponible sur https://dudobi.com/service-priority-levels/. La bibliotheque de cas se trouve a https://dudobi.com/success-stories/ et le recit de migration de la plateforme de communications a https://dudobi.com/success-stories/cloud-communications-platform/. Les reperes externes sont la fiche du reseau de partenaires AWS, https://partners.amazonaws.com/partners/0010h00001jDXbrAAG/, le profil vendeur AWS Marketplace, https://aws.amazon.com/marketplace/seller-profile?id=seller-d4sj47qcaygdc, et la liste des membres britanniques de RIPE NCC, https://www.ripe.net/membership/member-support/list-of-members/gb/.

Les pages de Dudobi et ses etudes de cas sont des informations de premiere partie: elles etablissent la maniere dont la societe decrit ses services et ses exemples, non une assurance independante de resultats futurs. Les pages AWS et RIPE NCC apportent un contexte d'identite et d'ecosysteme dans les limites propres a chaque annuaire.