Aller au contenu
BigTree108

Services de platform engineering

Services de platform engineering pour les entreprises dont les développeurs attendent les équipes d’exploitation pour livrer : plateformes internes pour développeurs, portails Backstage et catalogues logiciels, golden paths et modèles de services, infrastructure en libre-service, plateformes Kubernetes, environnements de prévisualisation et pipelines partagées, avec des ingénieurs plateforme dédiés à votre équipe ou une plateforme construite de bout en bout.

Travaux de platform engineering que nous prenons en charge

  • Plateformes internes pour développeurs

    Un parcours unique et supporté du commit à la production, avec l’environnement d’exécution, les pipelines, les secrets, l’observabilité et les accès déjà connectés, exploité par une équipe plateforme comme un produit, avec sa propre feuille de route, sa documentation et ses utilisateurs.

  • Portails développeurs Backstage

    Un portail Backstage dont le catalogue logiciel est alimenté depuis vos dépôts, avec les responsables et l’astreinte affichés pour chaque service, des plug-ins pour vos outils de CI, de cloud et d’incident, et une documentation conservée à côté du code. Des portails hébergés comme Cortex ou Port si vous préférez ne pas en exploiter un vous-mêmes.

  • Golden paths et modèles de services

    Des modèles dont part un nouveau service, avec le build, les tests, l’image de conteneur, le déploiement, les tableaux de bord et les alertes déjà en place, et des scorecards qui montrent quels services se sont écartés du standard.

  • Infrastructure en libre-service

    Bases de données, files d’attente, buckets et environnements entiers demandés depuis le portail ou une pull request et créés par des modules Terraform relus ou des compositions Crossplane, dans des limites de taille, de région et de coût.

  • Kubernetes comme plateforme partagée

    Clusters multi-tenant avec un namespace et un quota par équipe, network policies et règles Kyverno appliquées à chaque charge de travail, GitOps via Argo CD ou Flux, et une courte spécification d’application à la place de manifestes écrits à la main.

  • Briques de pipeline partagées

    Workflows GitHub Actions réutilisables, composants GitLab CI/CD ou modèles Azure Pipelines maintenus par l’équipe plateforme, de sorte que les étapes de signature, d’analyse et de déploiement atteignent chaque équipe par une simple mise à jour de version.

  • Environnements de prévisualisation éphémères

    Une copie éphémère de l’application pour chaque pull request, créée par la pipeline avec des données de test préchargées, liée depuis la revue et supprimée au merge.

  • Environnements de développement cloud

    Dev containers, GitHub Codespaces ou espaces de travail Coder qui reproduisent le build et ses dépendances sur n’importe quelle machine, pour qu’un nouvel ingénieur exécute le code dès son premier jour.

  • Indicateurs d’expérience développeur

    Indicateurs de livraison DORA, temps de build et de revue et courtes enquêtes auprès des développeurs mesurés avant et après chaque évolution de la plateforme, pour que sa valeur se démontre par des chiffres plutôt que par des affirmations.

Recruter des ingénieurs plateforme

  • ingénieurs plateforme dédiés

    Des Ingénieurs plateforme qui rejoignent votre équipe à temps plein, travaillent avec vos outils et votre processus, et rendent compte à votre responsable. Vous les interviewez ; nous portons le contrat ukrainien, la paie, la facturation et les congés.

  • Projets de Platform engineering

    Un lot défini de platform engineering, avec un périmètre, un plan arrêté et un responsable nommé de notre côté, qui porte le résultat et rend compte de l’avancement dans vos canaux.

  • Prestation continue de platform engineering

    Un service continu de Platform engineering : les mêmes personnes chaque mois, un backlog que vous priorisez, et des heures visibles dans notre portail et sur la facture.

La page Équipe dédiée explique comment les spécialistes rejoignent votre équipe, et la page Externalisation couvre la livraison de projet, les reprises et notre mode de facturation.

Qui intervient sur vos platform engineering

  • Ingénieurs plateforme

    La plateforme, ses modèles et le libre-service

  • ingénieurs Kubernetes

    Clusters multi-tenant et GitOps

  • Ingénieurs DevOps

    Pipelines partagées et infrastructure as code

  • Développeurs back-end

    Plug-ins Backstage et API de la plateforme

  • Ingénieurs SRE

    Observabilité et astreintes intégrées aux modèles

Comment nous construisons des plateformes

Une plateforme se gère comme un produit : les développeurs qui l’utilisent sont ses clients, la première version traite de bout en bout la demande la plus courante, et chaque ajout part d’un goulot d’étranglement mesuré plutôt que d’un outil que quelqu’un voulait essayer. Les golden paths restent optionnels et bien entretenus, afin que les équipes les choisissent parce qu’ils sont plus rapides.

Tout ce que fournit la plateforme est du code : modèles, modules Terraform, politiques et configuration du portail dans Git, publiés avec des numéros de version pour que les équipes se mettent à niveau à leur rythme. Sur une configuration existante, nous commençons par un audit en lecture seule et des entretiens avec les équipes qui déploient par son intermédiaire, puis un plan écrit classé par impact.

Autres services cloud, DevOps et sécurité

Cloud, DevOps et sécurité : vue d’ensemble

Questions sur le platform engineering

Dans quels secteurs travaillent vos ingénieurs plateforme ?

Surtout la fintech et la banque, où chaque équipe doit livrer par le même parcours audité ; les éditeurs de SaaS d’entreprise comptant de nombreuses équipes et de nombreux services ; l’e-commerce et la distribution ; les sociétés de cloud, d’hébergement et de télécoms qui proposent une plateforme à leurs propres clients ; les produits d’IA et de données qui ont besoin de capacité GPU et de pipelines à la demande ; et la santé, où les contrôles de conformité sont intégrés aux modèles.

Faut-il Backstage pour démarrer ?

Non. Une plateforme est le parcours supporté vers la production, et un portail n’en est qu’une porte d’entrée. De nombreuses équipes commencent par des modèles et du libre-service via des pull requests, et ajoutent Backstage lorsque le nombre de services justifie de tenir un catalogue.

En quoi le platform engineering diffère-t-il du DevOps ?

Les ingénieurs DevOps travaillent généralement au sein d’une équipe produit, sur ses pipelines et son infrastructure. Les ingénieurs plateforme construisent ce que toutes les équipes partagent : modèles, libre-service et parcours vers la production, pour que chaque équipe en fasse moins elle-même. Nous fournissons les deux, séparément ou ensemble.

En combien de temps les ingénieurs plateforme peuvent-ils démarrer ?

Lorsque le bon ingénieur plateforme est disponible, le démarrage ne dépend que de votre entretien, du NDA et de la cession de propriété intellectuelle. Sinon, nous lançons une recherche, qui fournit en général des profils de candidats sous deux à trois semaines, et personne ne démarre avant que vous ayez donné votre accord.

Comment recruter des ingénieurs plateforme via BigTree108 ?

Indiquez-nous le travail à réaliser, le niveau de séniorité et les horaires dont vous avez besoin. Nous vous proposons une ou deux personnes avec leurs profils, vous les interviewez comme vous le feriez pour votre propre recrutement, puis vous signez un seul contrat avec BIG TREE 108 LLC et recevez une facture par mois.

À qui appartient le travail qu’ils produisent ?

C’est vous. Chaque spécialiste a signé avec BigTree108 un contrat qui cède à l’entreprise tous les livrables, et notre contrat avec vous vous les cède à son tour. Le code, les maquettes et les documents sont livrés dans vos propres dépôts et outils, et non conservés à un endroit où nous seuls pourrions les modifier.

Vous construisez une plateforme interne pour développeurs ?

Indiquez-nous combien d’équipes déploient, où tournent leurs applications et ce qui les ralentit. Vous recevez une réponse sous un jour ouvré : un plan pour la première version, des profils de candidats, ou un périmètre d’audit.