Tintarabel

Ingénierie & systèmes numériques

Concevoir, développer et mettre en production des systèmes où la panne coûte cher.

Ingénieure Supélec, dix ans sur des équipements médicaux, industriels et de défense. Je cadre, je conçois, je développe et je déploie sur site. Ce que je livre tourne en production et reste reprenable par vos équipes après mon départ.

Formation
Ingénieure Supélec
Expérience
10 ans · médical, industrie, défense
Rôles
Développeuse · Tech lead · Chef de projet
Périmètre
De l'électronique à la direction de projet

§ 01 — Le spectre

Une vision large, au service du projet

Je ne remplace ni le responsable qualité, ni le responsable de production, ni le responsable produit: je travaille avec eux, en prise directe et sans intermédiaire de traduction. Ce que la largeur de vue apporte est ailleurs : elle permet de comprendre ce que le projet exige réellement, d'aller vite parce que je sais où se situe le problème, et de ne pas rester bloquée quand une zone du projet n'est couverte par personne.

Arduino
Raspberry Pi
Prototypage
CEmbarqué
Structured textAutomatisme
C++ · QtIHM · Applicatif
Python
Scilab
Traitement · Calcul
WordPressWeb
Bancs de testValidation
Process de devStructuration
Tech leadEncadrement
Multisite
International
Coordination

Ce que j'apporte n'est pas la maîtrise d'une pile technique en particulier : c'est la capacité à en prendre une en main et à livrer dedans. Cette liste indique où je suis déjà passée, pas où je m'arrête. Une méthode d'ingénierie solide se transporte d'un langage à l'autre et d'un métier à l'autre: c'est ce qui, en dix ans et sur trois secteurs, s'est révélé le plus rentable pour mes clients.

§ 02Interventions

Ce sur quoi on m'appelle

Quatre situations, souvent enchaînées sur la même mission.

02.1

Cadrage & spécification

J'interviens régulièrement sur des projets mal cadrés, parfois pas cadrés du tout : une intention, des contraintes implicites, et personne pour écrire ce qui doit être construit. Je pars du besoin réel (celui de l'exploitant, pas seulement celui qui a été formulé en réunion) et j'en tire une spécification tenable, chiffrée et testable.

  • Recueil et analyse du besoin
  • Spécification fonctionnelle
  • Choix d'architecture
  • Analyse de risques
  • Planning · Budget
  • Arbitrage de périmètre
02.2

Conception & développement

De la spécification au logiciel qui tourne : architecture, code, intégration avec le matériel, mise au point. Je travaille aussi bien sur une base neuve que sur un existant hérité dont plus personne n'a le mode d'emploi.

  • Embarqué C / C++
  • IHM Qt
  • Automates · Structured text
  • Python · Scilab
  • Arduino · Raspberry Pi
  • Interfaces matériel-logiciel
02.3

Industrialisation & déploiement

Un logiciel validé au bureau d'études n'est pas encore un produit livré. L'industrialisation transforme un développement en système exploitable : bancs de test et de validation, procédures reproductibles, mise en service sur site client, dans les conditions réelles d'exploitation et avec les équipes qui vont s'en servir au quotidien.

  • Bancs de test
  • Plan de validation
  • Procédure de déploiement
  • Release notes
  • Mise en service sur site
  • Transfert aux équipes
02.4

Direction technique & process

Tech lead, cheffe de projet, coordination d'équipes réparties sur plusieurs sites et plusieurs pays. Au besoin, je définis ou complète les process de développement, puis je les applique moi-même sur le projet en cours : un process qui n'a pas été éprouvé sur un livrable réel reste un document, et je livre des systèmes qui fonctionnent, pas des recommandations.

  • Direction technique
  • Process de développement
  • Revue de conception
  • Gestion de configuration
  • Projets multisites
  • Encadrement technique
§ 03Livrables

Le dossier comme outil de travail

Le dossier de conception n'est pas une formalité rédigée en fin de projet. Je le construis au fil de l'eau et je m'en sers activement : c'est lui qui fait apparaître les besoins non exprimés, qui oblige à trancher explicitement les choix techniques, et qui garantit que le produit livré couvre l'ensemble du besoin. Dans le médical et la défense, c'est aussi ce qui permet de démontrer que le système fonctionne, et pourquoi.

Dossier de conception

  1. Spécifications
  2. Analyse des modes de défaillance
  3. Stratégie de remontée d'erreurs
  4. Plan de test
  5. Process de développement
  6. Planning et budget
  7. Analyse de risques

Dossier de fabrication

  1. Release note
  2. Dépôt Git accessible et à jour
  3. Procédure de déploiement
  4. Bancs de test
  5. Bancs de validation
§ 04Méthode

Comment je travaille

Trois principes qui ne dépendent ni du secteur ni de la technologie.

Le juste besoin, pas la prouesse

Une spécification arrive rarement prête à être développée. Je la challenge systématiquement : quel est le besoin réel derrière la demande, qu'est-ce qui est indispensable à la mise en service, qu'est-ce qui peut attendre une version ultérieure.

L'objectif est d'éviter le sur-dimensionnement technique: ce qui est faisable n'est pas toujours utile, et chaque fonction ajoutée se paie ensuite en délai, en tests et en maintenance. Aucun compromis sur la qualité ; l'arbitrage porte sur le périmètre, pas sur la rigueur.

Opérationnelle rapidement dans une équipe existante

Je m'insère rapidement dans l'organisation en place (vos outils, votre gestion de configuration, vos rituels...). Je monte très rapidement en compétence sur un nouveau domaine, une nouvelle techno. J'observe, puis j'agis: si les process mis en place ne sont pas les standards de l'industrie du développement, et entrainenet des soucis de qualité ou délais, je prend les devant pour les faire évoluer de façon adaptée et progressive.

Concrètement, je commence par lire le code et les dossiers existants, par identifier et échanger avec les personnes qui détiennent l'information non écrite, et à faire tourner la solution déjà existante. Ensuite, je fais un rapide document de synthèse pour s'aligner sur l'objectif de la mission, et passe au développement.

Un système reprenable après mon départ

La mission est réussie quand une autre personne peut faire évoluer le système sans moi. Cela se prépare pendant le projet, pas la veille de la fin : documentation tenue à jour au fil du développement, dépôt Git propre et lisible, procédures de déploiement et de test exécutables telles quelles.

J'organise systématiquement un transfert avec les équipes qui reprendront la main, et je reste joignable ensuite. Un livrable que personne d'autre ne sait faire tourner n'est pas un livrable.

§ 05Outillage

Outils modernes, usage structuré

J'utilise l'IA dans mon travail quotidien d'ingénierie, et surtout j'en structure l'usage. La question n'est pas de savoir si ces outils font gagner du temps, c'est de définir précisément où ils en font gagner, où ils introduisent un risque, et quelles vérifications restent obligatoires avant qu'un élément entre dans un dossier.

Je les emploie là où le gain effectif et le contrôle possible :

  • Réalisation de prototypage rapide
  • Prise en main accélérée d'une base de code ou d'une technologie inconnue
  • En complément des reviews de code

Je ne laisse pas l'IA réfléchir à ma place pour débugger un bug complexe. Par contre, je l'utilise prioritairement sur les sujets simples, avec peu de valeur ajoutée, pour gagner en efficacité et délivrer à mon client plus de valeur sur les sujets de fond.

Pour cela, je mets en place une méthodologie de travail avec l'IA. En fonction du contexte, je peux également partager avec les équipes les bonnes pratiques que j'ai construites grâce aux divers retours d'expérience. Nous pouvons également, en s'appuyant dessus, travailler à la mise en place d'un cadre d'usage: quels outils, sur quelles données, avec quel niveau de relecture. Un cadre construit avec l'équipe est le seul qui soit réellement appliqué.

§ 07Parcours

Audrey

Ingénieure Supélec. Dix ans sur des systèmes qui n'ont pas le droit de tomber en panne : dispositifs médicaux, équipements grand public gros volume, projets de défense. Recherche et identification de cause de bugs, fiabilisation des solutions techniques.

Selon les projets, j'ai écrit du firmware, développé des IHM, monté des bancs de test, spécifié des systèmes qui n'avaient jamais été cadrés, tenu un planning devant un comité de pilotage et assuré la mise en service sur site. Je ne fais pas tout cela sur chaque mission, mais avoir couvert l'ensemble de la chaîne me permet de situer un problème là où il se trouve réellement, et non dans la seule couche que je connaîtrais.

Je fais ce qu'il faut faire. Si la mission demande d'apprendre une technologie que je n'ai jamais pratiquée, je l'apprends. Si elle demande d'écrire l'analyse de risques que personne ne veut écrire, je l'écris. Le critère est le même depuis dix ans : le système fonctionne, et vous pouvez le faire vivre sans moi.

Formation
Ingénieure Supélec
Expérience
10 ans
Secteurs
Médical · Industrie · Défense . Ouverte à d'autres domaines exigeants dans la Tech et l'Industrie
Rôles tenus
Développeuse · Tech lead · Cheffe de projet
Coordination
Projets multi-acteurs, internationaux et multisites
Formats
Régie · forfait · direction technique partagée
§ 08Contact

Parlons de votre système

Décrivez le contexte technique et l'échéance, je vous réponds rapidement sur ma possibilité de répondre à vos besoins et mes disponibilités.

LinkedIn

Ouvre votre logiciel de messagerie avec le message pré-rempli.