Offre d'emploi Architecte / Lead technique système SIGRHS

Contexte
L’Architecte / Lead technique garantit la cohérence technique de la solution et accompagne les équipes de réalisation sur l’architecture, la sécurité et la performance. Son intervention privilégie les décisions structurantes, les revues et la résolution des difficultés techniques, dans le respect de cette enveloppe de mobilisation.
Il traduit les besoins en orientations techniques compréhensibles et réalisables, explicite les arbitrages et veille à leur application par les équipes. Il assure la continuité entre la conception, la réalisation et la consolidation de la solution, tout en préparant la documentation nécessaire au transfert de connaissances.
Missions
• Phase 1 — Concevoir et sécuriser les choix structurants : définir l’architecture générale et détaillée, préciser les responsabilités des composants, le modèle de données et les principes de sécurité. Cadrer les API, les échanges entre composants et les choix techniques ; documenter les hypothèses, les contraintes et les arbitrages. Conduire les revues de code sur les points sensibles, identifier les risques de performance et proposer les ajustements nécessaires. Préparer les dossiers destinés à la DSI et à l’ASIN, en explicitant les choix retenus et les points nécessitant une validation.
• Phase 2 — Consolider et valider la solution : appuyer les corrections complexes et aider les équipes à établir un diagnostic technique. Revoir la stabilité et la performance, vérifier la cohérence des ajustements avec l’architecture retenue et valider les modifications relevant de son périmètre. Consolider la documentation finale en intégrant les évolutions réalisées, les limites connues et les points de vigilance utiles au transfert.
• Coordination — Accompagner les équipes et faciliter les arbitrages : assurer la cohérence des contributions back-end, front-end, intégration et infrastructure. Clarifier les interfaces et les dépendances, partager les recommandations et rendre les choix techniques compréhensibles pour le transfert. Signaler les risques et les désaccords techniques, présenter les options possibles et leurs conséquences, puis suivre la prise en compte des décisions retenues.
Compétences attendues
• Architecture applicative : concevoir une solution cohérente, définir les responsabilités des composants et formaliser les interfaces. Modélisation des données et conception d’API : structurer les données et les échanges en tenant compte des besoins, des contraintes et de l’évolutivité.
• Sécurité, performance et qualité : intégrer les exigences de sécurité dans la conception, analyser les points de fragilité et les performances, conduire des revues de code argumentées et établir un diagnostic technique à partir d’éléments vérifiables.
• Architecture de la solution : comprendre l’articulation entre le back-end Laravel, le front-end React, les données et l’infrastructure conteneurisée. Définir les responsabilités des composants, leurs interfaces et leurs dépendances ; documenter les flux et évaluer les impacts d’une évolution sur l’ensemble de la solution.
• Back-end Laravel : capacité à cadrer l’organisation du code, la séparation des responsabilités et l’implémentation des règles métier. Concevoir et revoir les API, la validation des données, les contrôles d’accès et la gestion des erreurs ; accompagner les développeurs dans la résolution des difficultés techniques.
• Front-end React : capacité à structurer les composants et les échanges avec les API, à organiser la gestion des données côté interface et à assurer la cohérence des parcours. Identifier les impacts des choix front-end sur la performance, la maintenabilité et la gestion des erreurs ; veiller à la cohérence entre les contrôles de l’interface et ceux du back-end.
• Données et intégrité : concevoir le modèle de données, expliciter les relations et les contraintes d’intégrité, et évaluer les conséquences des évolutions du schéma. Définir les contrôles de cohérence et accompagner les diagnostics de performance liés aux accès aux données, sans présumer du moteur de base de données retenu.
• Interopérabilité SIGRHS / DHIS2 : capacité à cadrer les interfaces d’échange, à définir la correspondance des données et à préciser les contrôles de cohérence. Documenter les contrats d’interface, le traitement des erreurs et la traçabilité des échanges ; vérifier la compatibilité avec les modalités d’intégration retenues pour le projet.
• Sécurité de l’architecture : capacité à traduire les exigences de sécurité en règles applicables aux interfaces, aux services et aux données. Définir les principes d’authentification, d’autorisation et de séparation des droits ; revoir la protection des échanges, la gestion des secrets et la traçabilité des opérations, en cohérence avec les mécanismes effectivement retenus.
• Déploiements conteneurisés et exploitation : comprendre la configuration des composants et leurs dépendances selon les environnements. Revoir les principes de déploiement, de mise à jour et de retour arrière ; définir avec les équipes d’infrastructure les besoins de journalisation, de surveillance et de diagnostic, sans imposer d’outil de conteneurisation ou d’orchestration non confirmé.
• Validation technique et performance : définir les vérifications utiles aux interfaces et aux flux critiques, interpréter les résultats des tests et prioriser les corrections. Évaluer les effets des ajustements sur la stabilité et la performance, puis documenter les limites connues et les points de vigilance pour le transfert.
• Documentation et transmission : produire des documents d’architecture exploitables, expliquer les arbitrages, animer les revues techniques et accompagner les développeurs dans l’appropriation des recommandations.
Livrables attendus
Les livrables sont à dimensionner selon les besoins du projet et l’enveloppe de mobilisation prévue ; ils doivent privilégier les éléments utiles aux décisions et au transfert.
• Phase 1 : dossier d’architecture générale et détaillée, modèle de données, principes de sécurité et cadrage des API ; synthèse des choix techniques et des arbitrages ; comptes rendus des revues avec recommandations et points de vigilance ; éléments de présentation destinés à la DSI et à l’ASIN.
• Phase 2 : synthèse des diagnostics et recommandations sur les corrections complexes ; conclusions des revues de stabilité et de performance ; dossier d’architecture mis à jour et éléments de transfert aux équipes.
Critères de réussite
• Des choix techniques explicités, cohérents entre les composants et compréhensibles par les équipes de réalisation.
• Des risques de sécurité, de stabilité et de performance identifiés, avec des recommandations priorisées et un suivi des points restant ouverts.
• Des ajustements validés sur leur périmètre technique et reportés dans une documentation conforme à la solution finale.
• Un transfert permettant aux équipes de comprendre l’architecture, les arbitrages et les limites connues, dans le respect de la mobilisation prévue.