# L'approche produit ### **Guide de l'approche produit** Un guide de l'approche produit est proposé par Selego. Si vous souhaitez organiser une formation pour les équipes de votre administration, contactez nous ! {% embed url="" %} # Guide de financement des Startups ## Guide de financement des Startups La méthode Selego s’inspire des méthodes lean startup, largement adoptées dans le secteur privé, pour permettre aux entreprises de lancer des produits numériques à la pointe de la technologie. L'une des caractéristiques de cette approche est de n'investir que dans des produits qui ont démontré leur valeur ajoutée réelle pour les clients ou l'entreprise. Tous les 6 mois, les décideurs au sein de l'entreprise réévaluent chaque projet en fonction des résultats obtenus. Ils décident alors de poursuivre, ajuster, ou stopper le financement, garantissant ainsi une allocation optimale des ressources et une agilité dans le développement produit. Ce mode de financement est inhabituel pour les entreprises privées, habituées à piloter par les moyens plutôt que par l'impact et souvent contraintes par des budgets trimestriels ou annuels. Cette section de la documentation offre des repères aux intrapreneurs pour gérer leurs levées de fonds privées, ainsi qu'aux décideurs et décideuses du secteur privé pour mieux piloter leurs investissements. # Pilotage du coût d'un produit numérique et contraintes liées à la comptabilité Lorsque l’on conçoit un produit numérique selon l’approche Selego, il est difficile d’avoir, au début des travaux, une idée très précise des coûts qu’il faudra allouer, puisque la construction du service suppose une adaptation permanente dans un contexte de forte incertitude (démarche entrepreneuriale et agile). L’avantage de ce mode de fonctionnement est qu’il permet d’ajuster le tir en permanence en fonction des résultats du service. Pour faciliter le pilotage financier d’un produit, la méthode Selego a distingué 4 phases dans la vie des produits numériques :
PhaseDescriptionCoût indicatif (dépend du périmètre et du type de sujet)
Investigation (2 mois)avant le lancement des travaux techniques, phase de validation du besoin utilisateur~15k €
Construction (~12 à 18 mois)lancement rapide d’une première version d’un produit (produit minimum viable) pour tester son utilité et juger de la pertinence d’une généralisationau moins 1 ETP + 250k à 500k€ / an
Accélération (~12 mois)période de croissance forte du service après la phase de construction, elle nécessite souvent, en fonction des objectifs, un renforcement temporaire de l’équipeau moins 1 ETP + entre 500k et 2M€ / an selon la complexité du produit
Pérennisation (jusqu’à débranchement)c’est une phase de stabilisation des coûts une fois que le service est mature. Il faut bien prévoir un coût d’exploitation annuel (= coût de fonctionnement) pour pérenniser une équipe capable d’opérer le service et de l’améliorer en continu. Il est recommandé de continuer à suivre les mesures d’impact du service chaque année pour déterminer s’il est toujours pertinent ou s’il convient de réduire l’investissement annuel / de le débrancher s’il n’est plus pertinent / de le faire évoluer si le contexte l’exige.au moins 40% d'internalisation + coût annuel en vitesse de croisière entre 500k € et 2M € / an
**En tout état de cause, il est essentiel de prévoir un budget récurrent dans le temps pour faire vivre le service numérique.** Il est illusoire de penser (1) qu’il est possible de planifier les coûts d’un projet numérique de A à Z et (2) que les coûts s’arrêteront lors de sa mise en service. Nos services numériques ne sont jamais réellement « finis » et nécessitent d’être maintenus et améliorés en continu. En effet, le risque d'obsolescence est permanent, ce qui s’explique par : \- (1) l'évolution des attentes des utilisateurs et de leurs pratiques numériques (par exemple le déploiement du smartphone ces dernières années ou encore plus récemment du télétravail) ; \- (2) l'évolution rapide des technologies numériques (par exemple le développement du cloud et des API) ; \- (3) l’évolution de la réglementation qui peut influencer le service numérique, ou des priorités politiques qui comme on le sait peuvent changer rapidement et remettre en question ce qui a été fait ou ce qui est prévu. **En matière de comptabilité,** il est difficile de convaincre chaque année une administration de prévoir des coûts récurrents plutôt que de prévoir un budget pour la construction d’un projet, même si la somme des coûts récurrents est bien plus faible que ce qu’aurait été le coût total du projet avec des méthodes « traditionnelles ». Une bonne pratique peut consister à prévoir une enveloppe annuelle sur-évaluée pour chaque produit numérique, quitte à la réévaluer en cours d’exercice si d’autres sources de financement sont trouvées pour la startup en cours d’année ou si la startup consomme moins que prévu. # Repères pour les décideuses et décideurs sur le coût des services numériques Au premier abord, le numérique coûte cher, même en utilisant des *méthodes agiles* et *lean startup*. **Ce coût est souvent mésestimé par les entreprises**. Cette section vise à donner des repères aux décideuses et décideurs. #### Les projets informatiques peuvent coûter jusqu'à des dizaines de millions d'euros En 2023, de nombreuses entreprises ont investi massivement dans des systèmes informatiques, avec certains projets dépassant les 10 millions d’euros. Quelques projets phares ont même franchi la barre des 100 millions d’euros, notamment dans les secteurs de la finance et des télécommunications. Cependant, malgré les efforts pour maîtriser les coûts, des dérives budgétaires continuent d’exister, notamment en raison de la complexité et de la rigidité des approches traditionnelles telles que le cycle en V. Un exemple marquant est celui de projets abandonnés après des investissements colossaux, comme certaines plateformes de gestion ERP qui, après des centaines de millions d’euros dépensés, n’ont jamais été pleinement fonctionnelles. L'adoption croissante de l'agilité et du cloud vise à réduire ces risques dans les entreprises privées. #### Le programme Selego, propose un pilotage de l'investissement en fonction de l'impact Les produits conçus selon l’approche Selego sont conçus selon un programme (investigation, construction, accélération, pérennisation), contrôlés en continu pour **s’assurer que les travaux vont dans le bon sens, d’ajuster l'investissement voire d’arrêter en l’absence de résultats satisfaisants.** En moyenne, l'investissement annuel constaté pour les startups est de l'ordre de grandeur suivant : * 500 000 € / an en phase de construction * de 1 000 000 € à 2 000 000 € / an en phase d'accélération et de pérennisation en fonction du périmètre du produit Le tableau suivant présente quelques repères supplémentaires sur des services numériques conçus selon l’approche Selego. Les coûts présentés dans le tableau correspondent aux coûts des prestations commandées (gestion de produit, développement, infrastructures et hébergement, déploiement, support utilisateur, design de service). Ils ne comprennent pas les coûts RH internes. # L'enjeu du pilotage par l'impact L’objectif d’un service numérique conçu selon l’approche Selego, c’est d’atteindre un impact maximal, de préférence avec des rendements croissants. L’objectif est de constater, en phase de pérennisation, que le **coût annuel augmente moins vite** (ou stagne, ou, mieux, baisse) que l’impact obtenu. Le succès est au rendez-vous quand les investissements des premières années portent leurs fruits. Quelques recommandations pour piloter, dans la durée, un produit numérique par l’impact : * Se mettre d’accord entre l’équipe, la hiérarchie et l’ensemble des financeurs sur les **mesures d’impact pertinentes** à suivre ; * Organiser un **comité d’investissement** régulièrement où l’équipe du service rend compte de son impact en fonction des coûts investis ; * Mettre chaque année en regard le coût annuel d’exploitation du service (plus le coût est élevé, plus en général l’équipe est grande) avec l’impact (**ratio impact/coût**), quand c’est pertinent de raisonner ainsi. Les **comités d’investissement** sont indispensables pour piloter les investissements d’une administration en matière numérique. Attention, un comité d’investissement n’est pas un comité de pilotage classique où l’on vérifie que le projet a bien respecté le cahier des charges (puisque dans la logique produit, il n’y a pas de cahiers des charges), mais un moment où les investisseurs se mettent en position de financeurs. A titre d’exemple, voici quelques exemples de questions qui peuvent guider la décision d’investissement lors d’un tel comité : * **Quel est l’objectif du service et de l’équipe sur laquelle j’investis ?** Par exemple : “aider les administrations à dématérialiser le maximum de démarche” ; “permettre aux associations de recruter facilement des bénévoles” * Ne pas hésiter à demander à voir une **démonstration du service** : le livrable d’une équipe produit, c’est aussi et surtout le site internet en ligne ; * **Combien suis-je prêt à investir dans le service pour les 6 prochains mois ?** En fonction de l’investissement consenti, quels sont les objectifs d’impact (réalistes) que je fixe pour le service ? Est-ce que je fais confiance à l’équipe pour atteindre les objectifs fixés dans les 6 prochains mois ? Quelle est mon estimation de “retour sur investissement” (ROI) ? * **Est-ce le moment d’“accélérer”,** c’est-à-dire d’augmenter l’investissement semestriel de mon ministère pour espérer démultiplier les résultats du service ? * **Est-ce le moment de ralentir ou d’arrêter les investissements car le service ne donne pas satisfaction ?** parce qu’il n’est plus prioritaire ? (En prenant en compte le fait que si on réduit l’investissement annuel, on peut dégrader la qualité de service ou limiter la capacité d’évolution.) **Le jeu des 7 différences** | Mode projet | Mode produit | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Le coût total du projet (hors maintenance) est calculé dès les premiers mois. | Le coût du produit est ajusté chaque année en fonction des objectifs fixés pour le service | | Le plus souvent, 80% du budget est dépensé avant la mise en service pour le public | Le plus souvent, 80% du budget est dépensé après la mise en service (en version bêta) | | L’objectif de l’investissement est la conformité au cahier des charges initial | L’objectif de l’investissement est le retour sur investissement (impact obtenu) | | Le plus souvent, les ⅔ des coûts sont liés à de la chefferie de projet, de la coordination, de la maîtrise d’ouvrage | Le plus souvent, les ⅔ des coûts sont liés à du développement et à du déploiement opérationnel | | Le pilotage se fait essentiellement sur les moyens, en l’occurrence sur la base des fonctionnalités développées, mais pas sur l’impact et l’utilité de ces fonctionnalités (car le service est rarement testé en conditions réelles) | Le pilotage se fait essentiellement sur l’impact constaté de la solution en ligne dès les premiers mois de travaux. | | Les coûts d’infrastructure (hébergement informatique) sont relativement élevés, car souvent dimensionnés dès le départ pour la charge maximale prévue | Les coûts d’infrastructure (hébergement informatique) sont gradués : ils sont négligeables au début et n’augmentent qu’en cas de traction avérée sur le service. | | Il existe un fort risque de dépenser de l’argent pour un produit qui sera obsolète au moment de sa mise en ligne, ou pire, qui ne sortira jamais (exemple : Scribe) | Dès les premiers investissements, un produit version bêta est mis en ligne pour tester le service en conditions réelles. | # La vie du produit \ Entre les phases , on a une moyenne de 30% de drop. \ \
# Investigation La phase d'investigation vise à comprendre les besoins réels des utilisateurs par une écoute attentive, en évitant de présumer des solutions. Sur une durée de 9 semaines, un intrapreneur, libéré partiellement de ses tâches habituelles et soutenu par un coach, interagit directement avec les utilisateurs pour identifier et tester des solutions potentielles à travers des prototypes. Cette approche assure que le développement technologique est réellement pertinent et impactant. # Construction La **phase de construction** correspond aux 6 à 12 premiers mois de votre service. Votre premier objectif est d'avoir de l'impact le plus rapidement possible, en servant votre premier utilisateur ou en opérant votre première transaction. Vous allez également devoir lancer le plus rapidement possible votre solution numérique afin de la confronter à la réalité terrain dès que possible. # Accélération **La phase d’accélération, qui suit une phase de construction réussie, vise une finalité : la croissance de l’impact du produit/service. L’atteinte de cet objectif passe notamment par un déploiement du service à plus large échelle, et peut s’accompagner d’un élargissement de l’équipe.** La phase d’accélération s’appuie donc sur les acquis d’une phase de construction, c’est à dire la création d’un service fonctionnel, validé par des premiers usagers. D’une durée d'environ 1 an, cette phase vise à structurer l’équipe, le produit, et les métriques utilisées autour d’un objectif : un déploiement à plus large échelle, pour amplifier l'impact final du produit ou du service. # Sortie d'incubation et pérennisation ### 💡Pourquoi pérenniser ? La pérennisation n’est pas seulement une formalité administrative, mais une stratégie essentielle pour **maintenir des services numériques robustes, agiles et capables de répondre aux besoins des usagers sur le long terme**. Les services numériques nécessitent **une amélioration continue** afin de rester pertinents et conformes aux évolutions des besoins des usagers, des cadres législatifs et technologiques. La pérennisation permet aussi de garantir la durabilité des investissements tant que l'impact est présent ou prouvé. Cela implique un financement récurrent avec **une ligne budgétaire dédiée**. ### ⌛ À quel moment déclencher la pérennisation ? La phase de pérennisation commence quand le service numérique a prouvé **son utilité réelle et a démontré son impact**. C’est la phase où les équipes de Selego se retirent petit à petit afin de laisser l'équipe porteuse en autonomie dans la gestion du service. La sortie d'incubation est ainsi souhaitée lorsque **le produit a atteint une maturité** démontrée par une adoption stable et régulière auprès de son public cible, confirmant qu’il répond à un besoin réel. Attention à ne pas vouloir sortir d'incubation votre startup trop vite. Une sortie d'incubation trop rapide peut ralentir le déploiement d'une solution numérique, ou risque de déstabiliser l'équipe en charge du produit. ### 🎯 Qu'est-ce qu'une pérennisation réussie ? Une pérennisation réussie repose sur plusieurs facteurs clés. Avant tout, il est nécessaire de maintenir **un expert métier**, et formé(e) en gestion de produit, au pilotage du service numérique. L’équipe doit être capable de **faire évoluer le produit**, dépassant ainsi le simple cadre de la correction d’anomalies, pour éviter le passage en maintenance. Le service doit maintenir une **relation constante avec ses utilisateurs**, en proposant un support accessible et en procédant à des tests réguliers pour garantir une **amélioration continue** et un haut niveau de satisfaction. Des **mesures d’impact** doivent également être suivies de façon régulière, afin d’ajuster les stratégies de déploiement et les investissements en fonction des résultats observés. ### 🛬 Adaptation des entreprises aux enjeux de la pérennisation La pérennisation d'une startup ne se limite pas à la simple continuité technique du projet, mais elle nécessite **une adaptation en profondeur des structures et des pratiques de l'entreprise** pour garantir son succès à long terme. Elle peut aussi impliquer l'intégration de nouvelles compétences, ce qui nécessite le recrutement de profils spécialisés et la révision des pratiques RH pour attirer ces talents. L'introduction de méthodes de travail comme le mode produit pourrait aussi exiger une adaptation de la gouvernance et de l'organisation afin de faciliter la mise en place d'une équipe intégrée et pluridisciplinaire. # Les standards # Securite # Sécurité ## Qu’est-ce qu’une sécurisation de produit chez Selego ? La sécurisation de nos produits vise à trouver un équilibre entre la réduction des risques et la performance technique, tout en maintenant une approche économique durable. Cette démarche repose sur une analyse approfondie des risques potentiels qui pourraient affecter les objectifs de nos produits, altérer l'expérience des utilisateurs, ou encore engendrer des impacts négatifs pour des tiers. Cette analyse est réalisée grâce à une compréhension fine des utilisateurs, de l'écosystème du produit et de l’architecture technique, et peut être renforcée par des expertises externes pour une vision plus complète. Le processus de sécurisation formalisé inclut des étapes critiques, comme la validation de la sécurité par des experts internes, notamment le Responsable de la Sécurité des Systèmes d'Information (RSSI) et le Délégué à la Protection des Données (DPO). L’objectif est d’assurer que les risques identifiés sont sous contrôle avant que le produit ne soit mis à disposition du public. ### Comment sécuriser votre service avec les outils de Selego ? Notre approche repose sur des outils automatisés et des processus rigoureux de sécurisation, basés sur les meilleures pratiques du secteur, notamment celles définies par l’ANSSI et l’OWASP. Nous intégrons des solutions comme AWS et MongoDB Atlas, qui respectent des standards de sécurité élevés (certifiés ISO 27001), pour héberger et protéger les données critiques. Nos équipes s’appuient également sur des outils de surveillance en temps réel et des tests réguliers de pénétration pour garantir la résilience et la robustesse de nos applications. Ces démarches permettent de générer des décisions de sécurisation, incluant des avis d'experts internes et externes, garantissant que chaque produit respecte les niveaux de sécurité requis avant sa mise en production. ### Quand se pose la question de la sécurisation de nos produits ? La sécurisation est au cœur de nos processus dès les premières phases de conception et de développement. Nous engageons une évaluation initiale des risques dès la phase d'investigation, afin que chaque étape de la construction du produit prenne en compte les objectifs de sécurité. Cela nous permet d’ajuster nos efforts en fonction des besoins identifiés au fur et à mesure de l’avancement du projet, pour éviter tout retard dans la sécurisation globale du produit une fois celui-ci mis en production. ### Quel modèle utiliser pour le dossier de sécurisation ? Un dossier de sécurité bien structuré est essentiel pour faciliter la compréhension des enjeux par l’ensemble des parties prenantes, y compris nos clients et partenaires. Ce dossier doit inclure des analyses de risques, des audits de sécurité, ainsi que des recommandations d'amélioration continue. Nous utilisons un modèle standardisé basé sur des référentiels reconnus tels qu’ISO 27001 et OWASP, assurant ainsi une traçabilité et une rigueur dans la gestion des évolutions du produit. ### Comment documenter les évolutions techniques au sein de ce dossier ? Les évolutions techniques et fonctionnelles de nos produits sont systématiquement tracées à travers des processus de gestion de versions ("releases", "pull requests"). Ces pratiques permettent de suivre chaque modification et d’évaluer les impacts potentiels sur la sécurité du produit, assurant ainsi une surveillance constante même après la mise en production. # Sécurité et homologation ## **Qu’est-ce qu’une homologation de sécurité ?** L’homologation de sécurité est une démarche qui vise à « trouver un équilibre entre le risque acceptable et les coûts de sécurisation, puis \[…] faire arbitrer cet équilibre, de manière formelle, par un responsable qui a autorité pour le faire » ([ANSSI](https://www.ssi.gouv.fr/guide/lhomologation-de-securite-en-neuf-etapes-simples/)). Son point de départ est une analyse des risques qui peuvent compromettre les objectifs recherchés par le produit, annuler ou dégrader les bénéfices pour ses usagers, ou pénaliser des tiers. Cette analyse s’appuie sur la connaissance qu’a l’équipe des usagers, de l’écosystème du produit et de son architecture technique. Elle peut être complétée par des expertises externes. Son aboutissement formel est la commission d’homologation, présidée par l’autorité d’homologation (la personne qui engage sa responsabilité quant à la maîtrise des risques), dont l’avis pourra s’appuyer sur l’expertise des membres de la commission, parmi lesquels siègent généralement les RSSI et DPO. La commission rend son avis sur dossier, ce qui exige de formaliser les analyses, et ce formalisme peut être adapté au produit concerné et à son contexte. ## Comment sécuriser et homologuer votre service avec MonServiceSécurisé ? L'ANSSI a développé un service de cybersécurité gratuit et 100% en ligne pour aider les entités publiques à sécuriser et à homologuer rapidement leurs sites web, applications mobiles et API : [**MonServiceSécurisé**](https://www.monservicesecurise.ssi.gouv.fr/) MonServiceSécurisé permet de référencer un service dès la phase d'investigation, en cours de développement ou déjà en ligne puis de le décrire afin de : * Accéder à une liste personnalisée de mesures de sécurité élaborée par l'ANSSI et obtenir une évaluation indicative du niveau de sécurité du service concerné (l'indice cyber), sur la base des mesures de sécurité déclarées par l'équipe comme ayant été mises en œuvre. * Générer en quelques étapes une décision d'homologation de sécurité incluant un ou plusieurs avis des membres de l'équipe sur le projet de décision d'homologation et de soumettre cette décision à la signature de l'autorité d'homologation (fonctionnalité bientôt disponible). ## **Quand se pose la question de l’homologation sécurité ?** L’homologation étant une obligation réglementaire, elle doit faire partie des préoccupations de l’équipe dès le départ. Dans le cadre d’une démarche itérative, les travaux peuvent être engagés à un rythme adapté à la trajectoire de construction et de déploiement du produit. Une première analyse des risques peut ainsi intervenir à l’issue d’une phase d’investigation, dont les éléments métier pourront ainsi guider les premières étapes de la construction afin que celle-ci prenne en compte les objectifs de sécurité, puis l’équipe pourra la compléter et initier dossier d’homologation relativement tôt dans le processus de construction ; ceci permettant de prononcer une homologation formelle sans délai lorsque le produit commence à concerner un public au-delà d’une expérimentation limitée… ## **Quel modèle utiliser pour le dossier d’homologation ?** Un dossier d’homologation bien construit permet aux membres de la commission d’homologation de se retrouver efficacement parmi ce qui est souvent une quantité d’information importantes, il est donc judicieux de s’appuyer sur les dossiers présentés par des équipes ayant fait l’objet d’une homologation précédemment ; on peut citer Le.Taxi qui fit figure de modèle au sein de beta.gouv.fr mais aussi s’inspirer par exemple du dossier Itou. ## **Est-il possible d’utiliser dans le dossier des liens ou renvois à des pages web dynamiques dans le dossier pour documenter les évolutions du code ?** #### **Le dossier d’architecture technique : quand et sous quelle forme ?** Le plus souvent, les produits dont le mode de diffusion est le Web et dont l’aspect « serviciel » rentre dans les normes en la matière suivent une architecture relativement standardisée : serveurs dédiés, virtuels ou conteneurisés qui prennent en charge l’implémentation des fonctionnalités, éventuellement complétés d’éléments d’infrastructure tels que bases de données, frontaux de cache ou de répartition de charge. Cette « architecture de référence » doit surtout être complétée par des éléments spécifiques au produit, tels que les choix de composants et de leurs versions. Notamment, il est de plus en plus critique dans le domaine du développement Web d’apporter une vigilance constante aux composants logiciels fournis par des tiers (« paquets », « dépendances », etc.) qui font régulièrement l’objet de vulnérabilités déclarées. Ces besoins de vigilance sont typiquement pris en compte par des outils automatisés en lien avec des forges logicielles telles que Github, et le dossier d’architecture technique peut donc en partie s’appuyer sur l’exposition sur les forges en question des rapports générés par ces outils. \*\*\*\* ## **Comment référencer les évolutions apportées au produit quotidiennement dans le contexte d’un dossier d’homologation ?** A l’image des évolutions affectant les paquets logiciels tiers, les évolutions techniques et fonctionnelles du produit doivent pouvoir être tracées et suivies antérieurement à l’homologation mais également une fois qu’elle a été prononcée, afin d’évaluer des risques nouveaux induits par ces évolutions. Les mécanismes usuels du développement dit « open source » permettant d’articuler différents niveaux de détail des évolutions fournissent un cadre pertinent pour cette traçabilité: des notions de livraisons ou « releases » étiquetées selon un schéma normé (tel que SemVer ou versionnage sémantique) afin de caractériser le degré de vigilance approprié, des notions de « pull request » qui correspondent à des regroupements d’évolutions formant un tout cohérent et documenté en dehors du code source, retraçant les intentions et les observations éventuelles, et enfin au grain le plus fin des « commits » qui permettent de rendre compte de chaque modification apportée. # Protection des données personnelles A chaque étape du développement d'un produit, il est nécessaire de savoir quelles questions se poser, quelles actions entreprendre, et quelles ressources mobiliser. ### ⚕ Hygiène : grands principes valables par tous les temps * Accepter que ces sujets coûtent du **temps** et des **ressources** et qu'ils ne soient pas (très) visibles des utilisateurs ; * **Plus tôt** on se pose les questions, plus il est facile et rapide d'y répondre et de traiter le sujet des données et de la sécurité ; * La relation de **confiance** qu'une équipe établit avec les référents-experts de ces sujets dans l'administration est son meilleur passeport pour la liberté et l'autonomie, davantage que les livrables attendus ; * En matière de données, **ce qui vaut pour soi vaut pour les autres** : que n'aimerions-nous pas voir circuler sur nous-mêmes ? ### 🔎 Phase d'investigation *9 semaines pour instruire un problème et envisager des solutions pour le résoudre*
Question à se poser * Quels outils utilise l'équipe pour communiquer, prendre des notes, conduire des entretiens ? * "Qui ça regarde ?" Est-ce que je suis en train de partager des données au delà du périmètre de l'équipe ou de ceux qu'elles regardent ? Exemple : Un entretien utilisateur peut être partagé avec l'équipe, le coach, l'environnement de l'équipe, mais sans doute pas au-delà. Est-ce que j'ai autorisé la lecture de mon Google doc par défaut, ou l'ai-je restreint au cercle d'intéressés ? * Est-ce que je sais ce qu'est une donnée personnelle ?
A faire * Je me documente sur les sujets RGPD & sécurité : * 💡 [Qu'est-ce qu'une donnée personnelle ?](https://www.cnil.fr/fr/cnil-direct/question/une-donnee-caractere-personnel-cest-quoi) [Qu'est-ce qu'une donnée personnelle sensible ?](https://www.cnil.fr/fr/definition/donnee-sensible) * 💡 [Guide d'hygiène informatique pour les systèmes d'information](https://www.ssi.gouv.fr/guide/guide-dhygiene-informatique/) & [Guide RGPD du dev](https://www.cnil.fr/fr/guide-rgpd-du-developpeur) * Je limite l'accès aux docs partagés à ceux que "ça regarde" et j'utilise des outils différenciés en fonction du degré de gêne (sensibilité) des informations. * Je minimise les informations collectées et supprime celles dont je n'ai pas besoin : après un entretien utilisateur, ai-je besoin de conserver dans mes notes toutes les données de le personne interrogée (date de naissance, numéro de tél, nom, etc.) ? > Exemple : Un plan de déploiement peut sans doute être sur Google doc en accès ouvert, mais des notes d'entretien utilisateurs, plutôt en accès limité.
A ne pas faire * Accepter des fichiers de coordonnées de personnes à contacter sans avoir vérifié le consentement de ces personnes ; * Discuter ou échanger des données personnelles sur des outils partagés (Trello, Slack).
### 🧱 Phase de construction produit *3 à 6 mois pour développer une première solution numérique et l'expérimenter auprès d'utilisateurs*
Questions à se poser * Quelle(s) donnée(s) personnelle(s) ai-je prévu de collecter ou d'utiliser dans mon produit, dans quel but précis ? Exemple : J’ai besoin de données de contact, et je demande le numéro de téléphone et l’adresse mail alors que l’adresse mail pourrait suffire pour contacter la personne. * Suis-je en train de collecter des données dont je ne sais pas vraiment à quoi elles serviront ? * Est-ce que je traite des données de santé ? Voir [définition de la CNIL](https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante) * Est-ce que le produit que je construit peut se rattacher à une démarche administrative existante, un service, ou un texte juridique permettant de justifier le traitement de certaines données ? Quelle est ma base légale de traitement ? * Qui est mon référent RGPD (DPO ou délégué DPO) ou sécurité ? * Quelle solution d'hébergement utilisé-je pour mon site ? Est-elle opérée ou localisée en France, en Europe ? Est-ce que je traite des données sensibles ou de santé qui nécessitent un hébergeur particulier ?
A faire * Je rédige les Conditions Générales d'Utilisation (CGU), mentions légales et Politique de Confidentialité (PC) et les soumet à l'équipe juridique. * Je recense toutes les données traitées et les finalités qui leur sont associées. * Si mon produit rentre dans l'un des [critères de la CNIL](https://www.cnil.fr/sites/default/files/atoms/files/liste-traitements-aipd-non-requise.pdf) : j'initie une analyse d'impact relative à la protection des donnée (AIPD, aussi appelée EIVP). * 💡 [Une AIPD, c'est quoi ?](https://www.cnil.fr/sites/default/files/atoms/files/infographie_aipd.pdf) * Je sensibilise très tôt les membres de mon équipe aux bonnes pratiques individuelles de sécurité informatique, en particulier les personnes appelées à administer le service.
### 🚀 Phase d'accélération *Mon produit a rencontré ses utilisateurs et démontré sa valeur en phase d'expérimentation ; je concentre mes efforts sur son déploiement à grande échelle (de 100 à 1 000 ou de 1 000 à 100 000 utilisateurs)*
Questions à se poser * Qui est le Responsable de la sécurité des systèmes d'information (RSSI) dans mon administration ?
A faire * Je reviens sur les actions des phases précédentes, en répète certaines (atelier risques) et mets à jour les documents correspondants. * \[Si AIPD] Je finalise l'analyse et sa validation avec le responsable de traitement. * Je partage le dossier avec le RSSI de mon administration, prends en compte ses retours et me renseigne sur l'autorité d'homologation.
A ne pas faire * Déstaffer les développeurs expérimentés dont on a plus que jamais besoin pour la montée en charge du produit ; * Croire que c'est fini !