Questions fréquemment posées

Concrètement, il s’agit le plus souvent de l’une de ces situations : une PME dispose d’une solution existante dont plus personne ne s’occupe vraiment, sans service informatique interne pour prendre le relais. Une organisation en croissance constate que son site et ses outils isolés ne suffisent plus et qu’il lui faut une plateforme, des intégrations et une exploitation stable. Une commune ou une administration a besoin d’un site web, d’un portail ou d’une application métier qui réponde aux exigences de protection des données, d’accessibilité et d’exploitation du secteur public. Ou une équipe de projet dispose de ses propres compétences et nous sollicite précisément pour le backend, l’infrastructure, l’intégration ou l’UX/UI – y compris aux côtés d’une agence existante ou d’une entreprise générale.

En termes d’ampleur, cela va d’une analyse technique de quelques jours à des projets de plateforme que nous développons et exploitons sur le long terme. Il n’y a pas de budget minimum. Nous sommes établis en Suisse et travaillons pour des organisations dans toute la Suisse et en Europe, en particulier en Allemagne, en Autriche et en Hongrie ; nous menons les projets en allemand, en anglais et en hongrois.

Il est utile que vous nous indiquiez brièvement à l’avance de quoi il s’agit : la situation de départ, les systèmes existants, le calendrier souhaité et les contraintes connues telles qu’une enveloppe budgétaire, une procédure de marché public en cours ou des échéances politiques. Savoir qui décide chez vous est également important pour nous. De notre côté, l’entretien réunit la personne qui sera ensuite responsable de votre projet – donc quelqu’un capable de répondre techniquement à vos questions.

À la fin de l’entretien, vous recevez notre appréciation : sommes-nous le partenaire qu’il vous faut. Si c’est le cas, soit une offre suit directement (lorsque le périmètre est clair), soit nous proposons une courte phase d’analyse (lorsqu’il ne l’est pas). Vous recevez en règle générale une offre dans un délai de cinq jours ouvrables ; elle est valable 30 jours.

Les offres, les contrats et la documentation nous engagent, et nous ne rédigeons de tels documents que dans des langues dont nous pouvons juger nous-mêmes chaque formulation. C’est pourquoi cette règle s’applique aussi aux demandes envoyées depuis la version française ou italienne de ce site. Dans le formulaire de contact, vous choisissez la langue dans laquelle nous vous répondons.

Elle ne s’applique pas au contenu de votre site web ou de votre application. Les traductions vers d’autres langues sont assurées par nos soins par défaut. Si vous préférez nous fournir vos propres traductions – par exemple via votre service de communication ou une agence de traduction –, nous les intégrons.

Pour cela, nous vous proposons volontiers un ou plusieurs ateliers avec vos équipes métier et, le cas échéant, votre informatique : que faut-il atteindre, qui utilise la solution, quels processus en dépendent, quelles contraintes techniques s’appliquent ? Il en résulte une liste d’exigences priorisées (indispensable / souhaitable) assortie d’une première estimation de la charge.

Le résultat vous appartient et est délibérément conçu pour rester exploitable sans nous : comme base de décisions internes, pour une demande de crédit ou de budget, ou comme point de départ d’un cahier des charges dans un appel d’offres. Pour les adjudicateurs publics, une réserve s’applique : si nous participons à l’élaboration du cahier des charges d’une procédure de marché public, cela peut constituer une préimplication susceptible de limiter notre participation ultérieure. Nous en parlons ouvertement avant de commencer.

Une analyse séparée est particulièrement pertinente lorsque l’état d’un système existant n’est pas clair, lorsqu’il faut trancher entre modernisation et reconstruction, lorsque la charge ne peut être estimée sérieusement qu’après avoir examiné le code et l’infrastructure – ou lorsque vous préparez un appel d’offres et avez besoin de bases solides.

Selon les cas, l’analyse porte sur le code, l’architecture, l’infrastructure, la sécurité, les flux de données et les prestataires tiers utilisés. Elle se conclut par un rapport écrit : état actuel, évaluation, options d’action avec estimation de la charge et recommandation claire. Le rapport est rédigé de manière qu’un autre prestataire puisse également s’en servir.

Cette première étape est un état des lieux : nous sécurisons les accès (hébergement, domaine, dépôt de code, zones d’administration), nous nous faisons une vue d’ensemble du code, de l’architecture, de l’infrastructure, des dépendances et des flux de données, et nous documentons l’état actuel. Il en résulte une évaluation des risques : où sont les failles de sécurité, quels composants sont obsolètes, quelles licences sont concernées, et ainsi de suite. Sur cette base, nous pouvons par exemple poursuivre ainsi : stabiliser et exploiter, moderniser par étapes, ou remplacer – ou autrement, selon l’état du système.

De votre côté, nous avons surtout besoin des accès existants et d’une personne de contact qui connaît le système du point de vue des utilisateurs. Si un changement de prestataire est prévu, nous accompagnons la reprise. Et si nous découvrons des problèmes de sécurité critiques pendant l’analyse, nous vous en informons sans délai et convenons de mesures d’urgence avant de poursuivre.

La procédure applicable dépend de la valeur du marché et du droit des marchés publics de votre canton (AIMP et lois cantonales d’application). Les marchés de cet ordre de grandeur relèvent souvent du gré à gré ou de la procédure sur invitation ; nous participons aux appels d’offres ouverts via simap.ch. Nous travaillons avec les modèles de contrats et de conditions générales des pouvoirs publics ; les points divergents sont clarifiés avant la signature. Si nous vous avons déjà soutenus dans la définition des exigences, nous abordons ouvertement la question de la préimplication avant le début d’une procédure.

Quelques-uns des principaux facteurs de coût sont habituellement l’étendue fonctionnelle, le nombre et la complexité des intégrations, la migration des données, le niveau d’exigence en matière de design, le standard visé pour l’accessibilité et les exigences de sécurité. L’hébergement, les licences et les prestations de tiers figurent toujours comme postes distincts ; les coûts d’exploitation courants sont indiqués séparément des coûts de projet.

Une offre de notre part contient le périmètre défini, les hypothèses retenues, les prestations incluses et exclues, le calendrier et les modalités de paiement. Pour les communes et les services publics, nous fournissons des chiffres utilisables pour des demandes de budget et de crédit – un plafond de coûts, réparti entre coûts uniques et coûts récurrents – et, sur demande, nous découpons les projets en phases réparties sur plusieurs exercices budgétaires.

Un prix fixe suppose que les exigences et les critères de réception soient consignés par écrit. Tout ce qui va au-delà est traité comme une demande de modification. L’avantage est la sécurité de planification : vous connaissez le montant avant le début de la réalisation et pouvez le budgéter et le faire approuver.

En régie, nous travaillons avec un suivi du temps transparent, un plafond de coûts fixé contractuellement, des rapports réguliers sur la charge et le budget restant, et la possibilité de mettre fin au projet aux étapes convenues. Vous recevez des justificatifs de charge dans les deux modèles.

Dans la pratique, nous combinons souvent les deux : prix fixe pour l’analyse et la conception, puis prix fixe pour la réalisation sur la base du concept.

Derrière cela se trouvent quelques mécanismes fixes : un document de périmètre écrit avec critères de réception, une priorisation en indispensable et souhaitable, des réserves déclarées ouvertement plutôt que des marges cachées, des rapports réguliers comparant la charge au budget, et une alerte précoce dès qu’un écart de plus de 10 pour cent se dessine – bien avant que le budget ne soit atteint.

Les changements en cours de projet sont normaux : les conditions-cadres évoluent, le marché ou la législation bougent, de nouvelles exigences arrivent de l’extérieur – tout cela ne se prévoit pas entièrement. Dans les projets menés de manière itérative, nous préférons échanger les nouvelles exigences contre d’autres moins importantes plutôt que de les additionner. Pour les communes, c’est particulièrement pertinent : un crédit supplémentaire est politiquement délicat, et nous informons assez tôt pour qu’il reste évitable.

Après le lancement, au cours duquel les rôles, les canaux de communication et les processus de décision sont fixés, nous travaillons par itérations de deux semaines. Après chaque itération, nous mettons l’état actuel à votre disposition – sur un environnement de test si vous le souhaitez –, afin que vous puissiez suivre vous-même l’avancement. Les décisions sont consignées par écrit, les exigences et les modifications sont gérées dans un système consultable par les deux parties. Les jalons se concluent par une réception formelle. Avant la mise en ligne viennent les tests de réception et, si nécessaire, une formation ; pour la phase de démarrage, nous convenons sur demande d’une disponibilité accrue.

La durée d’un projet dépend avant tout du périmètre fonctionnel, de la complexité technique et des intégrations nécessaires. La disponibilité des contenus et des données, ainsi que la rapidité des décisions et des validations, influencent également le calendrier.

Après l’analyse, nous établissons un plan de projet avec les phases et les jalons prévus. Pour les projets plus importants, nous pouvons répartir la réalisation en plusieurs étapes, de sorte que les premières fonctionnalités soient déjà utilisables pendant que d’autres parties sont encore en développement.

Chez les adjudicateurs publics, il faut en outre tenir compte de la durée d’une éventuelle procédure de marché public.

Cette personne est votre interlocutrice pour les délais, le budget et les décisions comme pour les questions métier et techniques – sans détour par un procès-verbal ni par un autre service. Une suppléance connaissant le projet est prévue pour les absences.

Après la mise en ligne, le contact ne bascule pas vers une hotline anonyme : les demandes de support passent par notre système de tickets, par courriel ou par téléphone et parviennent à des personnes qui connaissent votre système. Dans la mesure du possible, les mêmes personnes suivent un système du projet jusqu’à l’exploitation – c’est l’une des raisons pour lesquelles nous proposons l’exploitation.

Trois rôles sont importants, et ils peuvent être réunis en une seule personne : quelqu’un qui décide du budget et des validations ; quelqu’un qui connaît les processus métier et les contenus et teste les états intermédiaires ; et une personne de contact informatique pour les accès et l’infrastructure – ce peut aussi être votre prestataire informatique externe.

La charge se répartit de façon inégale : pendant la phase d’analyse, nous avons besoin de vous intensément ; pendant la réalisation, seulement ponctuellement pour des questions et des réceptions intermédiaires ; au moment de la réception, davantage à nouveau. Si votre capacité est limitée, nous prenons en charge des tâches supplémentaires telles que la migration des contenus, la coordination des tests ou même la direction de projet de votre côté. Nous menons volontiers les ateliers aussi chez vous ; lorsque cela a du sens et que votre infrastructure le permet, également à distance – cela économise du temps et des coûts. Les échanges courants se font en règle générale à distance.

Nous connaissons HERMES et nous nous y conformons : dans de tels projets, nous livrons les résultats prévus dans la forme prescrite – de l’étude à la mise en service en passant par la conception et la réalisation – et occupons les rôles prévus par votre manuel de projet. Une démarche agile à l’intérieur des phases HERMES est possible et courante aujourd’hui. Dans les environnements Scrum, nous assumons les rôles correspondants et travaillons dans vos sprints et vos outils.

Pour la collaboration avec votre informatique interne ou votre prestataire informatique existant, nous clarifions les responsabilités dès le début – typiquement, le prestataire exploite l’infrastructure et nous l’application. Aux côtés d’une agence ou d’une entreprise générale, nous prenons en charge un domaine clairement délimité, par exemple le backend, l’infrastructure ou l’intégration. Si votre propre équipe de développement doit reprendre la solution plus tard, nous prévoyons dès le départ la documentation, le travail commun sur le code et la formation.

Les raisons suivantes plaident habituellement pour une reconstruction ou une refonte : la technologie utilisée ne reçoit plus de mises à jour de sécurité, l’architecture ne supporte pas les nouvelles exigences, chaque extension devient disproportionnellement coûteuse, ou les coûts d’exploitation dépassent ceux d’un nouveau système. Si rien de cela ne s’applique, nous procédons par étapes : d’abord sécuriser (mises à jour, sauvegardes, surveillance), puis remplacer des composants isolés – un frontend, une interface ou la base de données – et, si nécessaire, consolider en un seul système plusieurs solutions isolées développées au fil du temps.

L’avantage de cette voie : l’exploitation continue, les coûts se répartissent sur plusieurs exercices budgétaires et les premières améliorations se font sentir rapidement. Le prix à payer est une phase de transition avec un système mixte, qui doit être proprement documentée. Quelle variante vous convient, c’est vous qui en décidez, sur la base d’une comparaison transparente des coûts, des risques et des bénéfices issue de notre analyse.

Nous examinons avec vous, entre autres, les questions suivantes : ce processus vous distingue-t-il des autres, ou est-il interchangeable ? Un produit standard couvre-t-il 80 pour cent du besoin sans contorsions ? Comment les coûts de licence sur cinq à dix ans se comparent-ils au développement plus l’exploitation ? Existe-t-il des exigences de souveraineté et de localisation des données que les produits standard ne peuvent pas satisfaire ? Et combien de systèmes existants doivent être raccordés ?

Les cas typiques de solutions sur mesure sont les portails clients et les plateformes en libre-service, les applications métier internes, l’automatisation de processus comportant des ruptures de support et les couches d’intégration entre ERP, CRM et systèmes métier. Souvent, la meilleure réponse est hybride : un produit standard comme base, complété par un composant sur mesure exactement là où cela en vaut la peine.

Nous distinguons deux choses : un prototype rend visibles très tôt les parcours et les interfaces, afin de pouvoir les tester avec de vrais utilisateurs – chez nous, il naît en règle générale directement dans le code, et non dans un outil de design séparé. Un MVP est déjà utilisable en production, volontairement réduit à l’essentiel. Les deux peuvent avoir du sens ; souvent, l’un suit l’autre. S’il manque un système périphérique – un ERP de test, par exemple –, nous le simulons à partir de la description de ses interfaces, afin que le développement n’ait pas à l’attendre.

Pour que le MVP ne devienne pas un goulet d’étranglement technique, nous veillons dès le départ à une architecture modulaire, à des modèles de données propres, à des interfaces documentées, à des technologies éprouvées et à des tests automatisés. Ce qui doit venir plus tard, nous le planifions par phases dans une feuille de route – ce qui permet aussi de répartir le budget sur plusieurs années. Après le MVP, nous analysons ensemble les retours, repriorisons et poursuivons le développement.

Une intégration commence en règle générale par une analyse des interfaces : quelles données circulent dans quel sens, quelle fraîcheur est nécessaire, quel est le système de référence ? Si un système n’offre pas d’API moderne, il existe généralement d’autres voies : des exports et imports réguliers, une synchronisation au niveau de la base de données ou – en dernier recours – une automatisation de l’interface utilisateur, dans laquelle un script utilise l’application comme le ferait un collaborateur, par exemple pour exporter régulièrement des données. Pour les systèmes propriétaires, nous travaillons avec l’éditeur.

Pour l’authentification unique, nous intégrons les systèmes de gestion des identités et des accès existants via les standards courants OpenID Connect, OAuth 2.0 et SAML, afin que vos collaboratrices et collaborateurs utilisent leurs accès habituels. Les interfaces que nous développons nous-mêmes sont documentées selon le standard courant (OpenAPI), afin de pouvoir être développées ensuite indépendamment de nous. Nous reprenons les données des anciens systèmes, nettoyage compris.

Tout commence par un inventaire : contenus, données, URL, intégrations, domaines, entrées DNS et services de messagerie. Nous migrons contenus et données, réalisons des migrations de test et comparons les résultats avant la migration en production. Sur demande, nous mettons à disposition un système de préproduction – pour la durée du projet ou de façon permanente – sur lequel vous pouvez vérifier le nouvel état à l’avance ; il est fermé aux moteurs de recherche, tout le reste peut y être testé. Pour la visibilité dans les moteurs de recherche, nous établissons un plan de redirections (redirections 301 pour chaque URL existante), mettons à jour les sitemaps et surveillons après la mise en ligne les pages d’erreur, les positions et les journaux.

La bascule elle-même a lieu dans une fenêtre en dehors des heures de forte utilisation. L’ancien système reste opérationnel jusqu’après la réception, de sorte que nous pourrions revenir en arrière à tout moment. Si nécessaire, les interfaces existantes fonctionnent pendant une phase de transition avec les deux systèmes, jusqu’à ce que tous les processus dépendants soient basculés.

Selon la solution, nous utilisons des tests unitaires, d’intégration et de bout en bout, complétés par des tests de performance et des vérifications sur différents navigateurs et appareils. Chaque modification passe automatiquement par les tests et par une revue effectuée par une deuxième personne avant d’être validée. Nous recommandons, pour la durée du projet, un environnement de test sur lequel vous pouvez vérifier vous-même les états intermédiaires ; il est commandé séparément et peut être désactivé ensuite.

La réception suit des critères convenus à l’avance : vous testez durant une phase définie, les erreurs trouvées sont classées par gravité et corrigées dans des délais fixés, et la mise en ligne n’a lieu qu’après votre validation. Nous consignons les décisions techniques dans de courtes notes d’architecture (ADR) ; à la clôture, vous recevez une documentation technique et un manuel d’exploitation.

Pour les communes et les services publics, il existe des prescriptions légales en matière d’accessibilité, qui varient d’un canton à l’autre ; le standard suisse eCH-0059 renvoie pour cela à WCAG 2.1 AA. Si l’accessibilité fait partie du mandat, nous en tenons compte dès le design (contrastes, structure, gestion du focus), pendant le développement (HTML sémantique, utilisation au clavier, balisage correct des formulaires et des composants) et lors de la vérification : tests automatisés, tests manuels au clavier et au lecteur d’écran et, sur demande, un audit externe par un organisme spécialisé indépendant. L’accessibilité peut être convenue comme critère de réception.

Nous examinons les sites existants dans le cadre d’un audit et montrons ce qu’il faut faire. Les composants que nous livrons sont conçus pour être accessibles ; qu’une page le reste se décide ensuite au niveau de la rédaction – dans le choix des composants, les textes alternatifs, la structure des titres et les documents téléversés. C’est pourquoi nous formons votre équipe rédactionnelle à la création de contenus accessibles et apportons un soutien technique pour la déclaration d’accessibilité. Veuillez noter en outre que les contenus de tiers et les fonds de PDF existants ne peuvent, le cas échéant, pas être rendus accessibles d’une simple pression sur un bouton.

Un contrat de maintenance chez nous comprend les mises à jour régulières du système d’exploitation, des frameworks, des bibliothèques et des dépendances, y compris la correction rapide des failles de sécurité connues ; la surveillance avec alerte, afin que nous remarquions les incidents avant vous ou vos clients ; des sauvegardes dont la restauration est testée ; des fenêtres de maintenance annoncées ; une documentation de toutes les modifications apportées au système de production ; et, sur demande, un rapport d’exploitation portant sur la disponibilité, les mises à jour appliquées et les points ouverts.

Nous prenons également en maintenance des systèmes qui ne viennent pas de nous – après un examen, afin de savoir de quoi nous assumons la responsabilité. Une reprise d’exploitation se déroule en trois étapes : analyse, sécurisation de l’état actuel, transfert vers l’exploitation régulière. Vous pouvez aussi nous confier l’exploitation et la maintenance sans projet de développement préalable.

Un forfait d’exploitation comprend typiquement l’hébergement et l’infrastructure, la maintenance (mises à jour de sécurité et de frameworks, surveillance, sauvegardes), un contingent de support et les délais de réaction convenus. Sont facturés séparément les licences de tiers ainsi que les développements qui vont au-delà de l’exploitation.

Pour votre planification budgétaire, nous fournissons un chiffre fixe pour les coûts récurrents, normalement avec une durée de douze mois et un délai de résiliation de trois mois.

Les demandes de support sont priorisées selon leur impact :

Pour chaque niveau s’appliquent un délai de réaction et un délai cible de résolution, inscrits dans le contrat. Les canaux d’annonce sont le système de tickets, le courriel et le téléphone ; si une panne n’est pas résolue dans le délai attendu, un processus d’escalade s’enclenche jusqu’à la direction.

En dehors des heures de support, la surveillance continue de suivre les systèmes et déclenche automatiquement des alertes ; les annonces sont traitées le jour ouvrable suivant, sauf si une permanence a été convenue. Les failles de sécurité critiques dans les composants utilisés sont corrigées par défaut dans les 48 heures, indépendamment du rythme de maintenance ordinaire. Le délai de rétablissement (RTO) et la perte de données maximale (RPO) peuvent être convenus contractuellement.

Quelle variante est judicieuse, nous vous le recommandons en fonction des données traitées : pour un site web sans besoin de protection particulier, un emplacement dans l’UE est le choix économique et ne pose pas de problème du point de vue de la protection des données ; l’envoi des courriels transactionnels est alors assuré par AWS SES, avec traitement en Irlande. Dès que des données personnelles d’une administration, des données sensibles ou des exigences cantonales entrent en jeu, nous recommandons la Suisse comme lieu de stockage et de traitement – nous choisissons alors chaque service concerné, du centre de calcul à l’envoi des courriels, de sorte que ni les données ni les accès ne quittent le pays. Notre propre infrastructure se trouve aujourd’hui en Allemagne, donc au sein de l’UE ; la surveillance et la journalisation y sont également exécutées.

Les sauvegardes sont créées quotidiennement et stockées chiffrées sur un site séparé de l’exploitation. Par défaut, nous les conservons 30 jours ; selon le système et la méthode de sauvegarde, une durée plus longue s’applique, et les anciens états sont régulièrement épurés. La restauration est testée ; nous en fixons le rythme par système. Les journaux font l’objet d’une rotation et sont sauvegardés chiffrés ; les données de surveillance sont en règle générale non critiques. Vous recevez sur demande la liste des sous-traitants utilisés, qui fait également partie du contrat de sous-traitance. Lorsque certains services – par exemple pour l’envoi de courriels ou des outils de développement – pourraient traiter des données en dehors de l’emplacement choisi, nous le déclarons ouvertement et proposons une alternative si vos exigences l’imposent.

Vous pouvez aussi rester sur votre infrastructure d’hébergement existante ou nous confier l’exploitation de votre propre environnement cloud ou serveur. L’hébergement et le développement peuvent être obtenus séparément. Et parce que nous misons sur des technologies standard, un changement ultérieur d’hébergeur est possible sans redéveloppement.

Un contrat de sous-traitance (DPA) est nécessaire dès que nous traitons des données personnelles pour votre compte – donc pratiquement toujours dans l’hébergement et l’exploitation, mais généralement pas dans le développement pur avec des données de test. Quelles données nous traitons concrètement dépend de la solution et est consigné dans le contrat. En développement comme en exploitation s’applique le principe de la protection des données dès la conception : minimisation des données, modèle d’accès fondé sur le principe du moindre privilège, chiffrement en transit, sauvegardes chiffrées, environnements séparés et aucune donnée personnelle de production dans les systèmes de développement et de test. Nos mesures techniques et organisationnelles sont documentées et vous pouvez les consulter.

À la fin du contrat, vos données sont exportées et remises, puis supprimées par défaut dans un délai de 30 jours – avec confirmation écrite. Pour une analyse d’impact relative à la protection des données ou un contrôle préalable selon le droit cantonal, nous fournissons l’apport technique. Et si vous voulez savoir quelles données votre site actuel envoie aujourd’hui à des tiers – suivi, polices, cartes, intégrations –, nous l’analysons et montrons ce qui devrait changer.

Les accès à vos systèmes sont personnalisés, protégés partout où c’est possible par une authentification multifacteur et retirés immédiatement lorsqu’une collaboratrice ou un collaborateur quitte l’entreprise. Les accès administratifs sont limités à peu de personnes et traçables. Les mots de passe, clés d’API et autres secrets ne se trouvent jamais dans le code, mais dans un système prévu à cet effet. Chaque modification passe par une revue de code, les dépendances sont contrôlées automatiquement à la recherche de vulnérabilités connues, et nous appliquons par défaut les mises à jour de sécurité critiques dans les 48 heures. Pour des besoins de protection plus élevés, nous menons des revues de sécurité et organisons sur demande des tests d’intrusion externes.

Si un incident survient malgré tout, un processus établi s’enclenche : détection par la surveillance et l’alerte, confinement, information à votre intention dans les 24 heures avec une personne de contact désignée, correction, rétablissement, puis un rapport écrit indiquant la cause et les mesures. En cas d’obligation d’annonce auprès du PFPDT ou de l’autorité cantonale de protection des données, nous vous soutenons avec les informations nécessaires. Vous recevez nos mesures de sécurité sous forme documentée – par exemple pour un examen de prestataire.

Cette distinction nous importe parce qu’elle est souvent brouillée lors des examens de prestataires : la certification du centre de calcul couvre la sécurité physique et l’exploitation de l’infrastructure. Pour tout ce qui se situe au-dessus – l’application, les accès, le processus de développement, le traitement de vos données –, c’est nous qui sommes responsables, et aucune certification externe ne vaut pour cela.

Ce que nous vous fournissons à la place : un concept de sécurité documenté, la liste des mesures techniques et organisationnelles, des questionnaires de sécurité de votre organisation dûment remplis et une auto-déclaration pour les procédures de marché public.

Par défaut, vous recevez l’intégralité du code source à la fin du contrat, sans frais supplémentaires, avec la documentation – sous la forme d’un état complet sans historique des versions, à partir duquel vous ou un autre prestataire pouvez poursuivre le développement ; pour un pur projet de développement, c’est donc à son achèvement. Qui souhaite un aperçu pendant la durée du contrat peut commander un dépôt miroir en lecture seule, que nous mettons à jour à chaque version – une charge distincte, facturée séparément. Nos propres composants réutilisés sont signalés comme tels : vous obtenez sur ceux-ci un droit d’utilisation non exclusif et illimité dans le temps dans le cadre de votre solution – y compris le droit de les modifier et d’en charger des tiers – ainsi que leur code source dans l’état déployé. Nous documentons les composants open source utilisés avec leurs licences, afin que vous sachiez à tout moment ce que contient votre solution.

La documentation couvre l’installation, l’architecture, les interfaces et l’exploitation – rédigée pour des personnes qui n’ont jamais vu le système.

Concrètement : vos données peuvent être exportées intégralement, dans les formats prévus par les technologies utilisées – sauvegardes de base de données, exports structurés, fichiers dans leur format d’origine. Les interfaces sont documentées. L’application est conteneurisée ; avec le code, vous recevez les définitions de conteneurs correspondantes, de sorte que vous pouvez construire de nouvelles versions de façon autonome. Un manuel d’exploitation décrit les exigences système et les recommandations d’exploitation. Et nous n’intégrons aucune dépendance à des composants non transférables.

Un changement se déroule comme une remise ordonnée, avec une phase de transition durant laquelle nous répondons aux questions du nouveau prestataire. Nous facturons pour cela la charge effective au tarif horaire normal – il n’y a pas de « frais de sortie ». Pour le cas où nous viendrions nous-mêmes à défaillir : la documentation est à jour, chaque système est connu de plusieurs personnes chez nous, et sur demande nous convenons d’un dépôt miroir ou d’un dépôt du code auprès d’un tiers séquestre. À la fin du contrat, vous recevez le code, les données, la documentation et une confirmation de suppression pour tout ce qui reste chez nous.

Après le projet, vous pouvez notamment décider si nous exploitons la solution entièrement ; si nous assurons la maintenance tandis que l’hébergement reste chez votre prestataire actuel ; si vous nous mandatez uniquement au besoin pour des développements, par exemple via un contingent d’heures ; ou si votre informatique interne, respectivement un autre prestataire, reprend la main – avec remise, formation et une phase de transition durant laquelle nous restons joignables pour les questions.

Dans tous les cas, vous recevez la documentation complète à la clôture du projet. Nous soutenons votre propre équipe de développement après la reprise si vous le souhaitez, et nous formons vos collaboratrices et collaborateurs – rédaction, administration ou développement – afin qu’ils puissent utiliser et entretenir la solution de manière autonome.