Fiche de poste : Développeur Back et architecte logiciel
1. Contexte et finalité du poste
Edu-Kit est une plateforme de virtualisation à vocation pédagogique destinée aux établissements d’enseignement supérieur et technique. Le poste s’intègre au pôle Développement (3 personnes au total) et porte spécifiquement la conception applicative côté serveur ainsi que l’architecture logicielle d’ensemble.
La finalité du poste est double : (1) livrer des API robustes, performantes et sécurisées, qui orchestrent la gestion des utilisateurs, des environnements de cours, des machines virtuelles et de la supervision ; (2) garantir la cohérence architecturale du système sur la durée, en pilotant les choix structurants et leur documentation sous forme d’ADR.
Le titulaire travaille en polyvalence avec les deux autres développeurs (un orienté front et UX, un polyvalent référent qualité), au sein d’une équipe agile fonctionnant en sprints Scrum de 3 semaines.
2. Missions principales
- Concevoir et développer les API ASP.NET Core qui exposent les fonctionnalités d’Edu-Kit (gestion des organisations, des utilisateurs, des environnements, des machines virtuelles).
- Définir et faire vivre l’architecture logicielle : choix structurants (clean architecture, CQRS, contrats gRPC inter-services), arbitrages technologiques, documentation des décisions sous forme d’ADR (voir l’index ADR).
- Modéliser les données dans PostgreSQL et concevoir les contrats d’échange (REST, gRPC, messages RabbitMQ).
- Encadrer les pratiques d’architecture au sein de l’équipe (revues d’architecture, partage des bonnes pratiques).
- Contribuer aux tests automatisés (unitaires, intégration) en lien avec le référent qualité.
3. Responsabilités détaillées
- Responsable final de l’architecture logicielle du système : cohérence d’ensemble, choix structurants, documentation des décisions sous forme d’ADR.
- Responsable final du développement des API back, de la modélisation des données et des contrats gRPC inter-services.
- Co-responsable, avec le développeur front, des contrats d’API REST côté back.
- Contributeur sur la documentation produit, les schémas d’architecture, et les arbitrages de portée technique (choix de bibliothèques, patterns).
- Garant du respect des principes architecturaux retenus (séparation des couches, testabilité, indépendance des contextes).
4. Compétences techniques requises
| Compétence | Niveau attendu |
|---|---|
| ASP.NET Core (Minimal APIs, EF Core) | Avancé |
| C# moderne (records, async/await, pattern matching) | Avancé |
| Clean architecture, CQRS, MediatR, FluentValidation | Avancé |
| PostgreSQL et conception de schémas relationnels | Confirmé |
| RabbitMQ et architectures orientées messagerie | Confirmé |
| gRPC et conception de contrats Protobuf | Confirmé |
| SignalR pour les communications en temps réel | Confirmé |
| Tests xUnit et stratégies de tests automatisés | Confirmé |
| Git et flux Git d’équipe (voir Workflow Git) | Confirmé |
5. Compétences non techniques attendues
- Capacité à formaliser des décisions techniques et à les expliquer clairement, à l’écrit comme à l’oral, à des interlocuteurs de niveaux différents.
- Esprit critique : savoir remettre en question un choix structurant lorsque le contexte évolue, et arbitrer entre élégance et pragmatisme.
- Sens du collectif : ouverture aux revues d’architecture, capacité à transférer ses connaissances aux autres membres du pôle Dev.
- Communication écrite et orale en français et en anglais (équivalent niveau B2).
- Rigueur dans la documentation : tout choix structurant fait l’objet d’une ADR rangée dans le repo et discutée en amont.
6. Livrables types
- API ASP.NET Core déployées et documentées (Swagger), conformes aux contrats convenus avec le front.
- Décisions d’architecture documentées (ADR) versionnées dans le repo et discutées en revue de sprint le cas échéant.
- Schémas d’architecture à jour, lisibles, exportables vers la documentation projet.
- Tests unitaires et d’intégration couvrant les flux back critiques.
- Demandes de fusion revues par au moins un autre développeur avant intégration.
7. Indicateurs de réussite
| Indicateur | Cible |
|---|---|
| Couverture de tests sur le code back | ≥ 75 % sur les couches application et domaine |
| Délai moyen entre l’identification d’un besoin de décision d’architecture et la publication de l’ADR | < 1 sprint |
| Nombre d’ADR rejouées (décision révisée car prématurée) | À surveiller, idéalement < 10 % |
| Temps moyen de revue de code back par les pairs | < 1 jour ouvré |
| Stabilité de l’API en production (taux d’erreur 5xx) | < 0,1 % des requêtes |
8. Interactions principales
- Développeur front et UX : contrats d’API REST, alignement sur la modélisation des données, ergonomie des points d’intégration.
- Développeur polyvalent et référent qualité : stratégie de tests, couverture des cas limites, pratiques de testabilité.
- Ops Plateforme et supervision : intégration applicative avec le cluster Proxmox et le qemu-guest-agent.
- Ops Sécurité et CI/CD : conception des flux d’authentification et d’autorisation, intégration Keycloak.
- Ops Plateforme et IaC : gestion des secrets via Vaultwarden, déploiement applicatif via OpenTofu et Ansible.
- Product Owner du sprint : priorisation, arbitrages techniques avec impact sur le périmètre.