feat: Add new templates for tech and employment monitoring reports
- Created a new tech and AI monitoring report template for weekly updates. - Added an employment and developer trends report template to analyze market conditions. - Updated CLAUDE.md to include new directories for sources and templates. - Introduced a detailed structure for capturing key signals, OKR alignment, and actionable insights.
This commit is contained in:
parent
c93ba97a6f
commit
92946d3203
48 changed files with 3572 additions and 1 deletions
|
|
@ -1,2 +1,3 @@
|
||||||
[ ] - Reprendre rdv dentiste
|
|
||||||
[ ] - Facture HPA
|
[ ] - Facture HPA
|
||||||
|
[ ] - Vérifier Charte IA
|
||||||
53
05-revues/coaching/2026-05-11.md
Normal file
53
05-revues/coaching/2026-05-11.md
Normal file
|
|
@ -0,0 +1,53 @@
|
||||||
|
---
|
||||||
|
type: coaching
|
||||||
|
date: 2026-05-11
|
||||||
|
session: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
# Session de coaching — 11 mai 2026
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Alignement (Ikigai)
|
||||||
|
|
||||||
|
**Observation :** Ton ikigai est maintenant clairement formulé : clarifier le chaos, construire utile, faire grandir les gens, sans sacrifier le vivant. L'hypothèse à 90 jours est lucide — tu ne cherches pas une mission unique, mais des conditions de vie où tu es vraiment vivant. Hier, tu as investi temps et rigueur dans deux veilles structurées (tech/IA hebdo, emploi/devs mensuel), deux playbooks complets, deux templates. Ça, c'est du travail de clarification du chaos, c'est utile. Le problème n'est pas la boussole. C'est que tu la suivis quand tu crées de la structure, mais on ne voit pas encore le "sans sacrifier le vivant" se matérialiser dans ton semaine.
|
||||||
|
|
||||||
|
**Question :** Hier, en construisant ces deux veilles et playbooks, tu as passé combien de temps avec tes enfants, avec ton conjoint, ou hors écran ? Était-ce une décision consciente d'arbitrage, ou tu l'as juste découvert après-coup ?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Performance (Projets / OKRs)
|
||||||
|
|
||||||
|
**Observation :** Tu as un pattern clair maintenant. Depuis la session du 17 avril, tu as ajouté : deux playbooks, deux templates, une première veille, amélioré le playbook tech/IA initial. C'est du travail concret et structurant. Mais ce pattern est une répétition depuis avril : tu bâtis des systèmes (veilles, playbooks, coaching, PKM lui-même) avec une rigueur impressionnante, et en parallèle tu dis que ton vrai goulet est de "choisir ce que tu laisses de côté". Hier, tu n'as rien laissé de côté — tu as encore ajouté. Sur tes OKRs Q2, tu as des KRs clairs (équipe IA, PAI dev, bases techniques) mais toujours pas de revues hebdo consolidées qui montreraient l'avancement réel. L'absence de ce rituel simple n'est pas un accident.
|
||||||
|
|
||||||
|
**Question :** Ces structures que tu bâtis — veilles, playbooks, coaching — avancent-elles vraiment tes OKRs Q2 chez Seenaps/Factory, ou c'est un détour que tu acceptes de faire parce qu'il te rassure davantage que de t'exposer aux vrais blocages des projets ?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Équilibre (Rôles)
|
||||||
|
|
||||||
|
**Observation :** Ton couple resté nommé comme "sous-investi" depuis la session du 12 avril. Tu l'as explicité de nouveau le 17 avril. Depuis, une semaine s'est écoulée, et ce que tu as construit (veilles, playbooks, templates) est entièrement du travail pro/systèmes, zero moment famille visible. On est dimanche soir — tu racontes une semaine très remplie de "construction utile". Rien sur le temps passé avec Aurélie, rien sur les enfants (à part "j'ai une veille sur le coaching d'équipe, ca m'intéresse"). C'est une observation douce mais directe : le couple continue à être ce rôle que tu reconnaîs important mais que tu traites comme une intention, pas une action.
|
||||||
|
|
||||||
|
**Question :** Si je te demande " C'est quoi ton engagement concret avec Aurélie cette semaine ? ", tu me dis quoi — une intention ou un fait de calendrier non-négociable ?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Question centrale de la semaine
|
||||||
|
|
||||||
|
**Tu crées beaucoup de structure — c'est une vraie force. Mais tu confonds créer la structure avec l'habiter.** Les deux veilles que tu viens de poser, le coaching que tu as lancé : ce sont des outils excellents. Or pendant que tu les posais, le vivant continuait sans toi. La question n'est plus "comment tu clarifes" le chaos — tu le fais très bien. C'est : **As-tu la capacité, cette semaine, de laisser au moins une structure inachevée pour protéger un moment qui compte vraiment pour toi, et d'accepter d'être "incomplet" plutôt que de tout terminer ?**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Insights pour la semaine
|
||||||
|
|
||||||
|
- Tu dis être bon à "structurer le chaos". Tu l'es. Mais tu dois distinguer : clarifier ce qui compte ≠ finir ce qu'on a commencé. La seconde t'ajoute de la friction avec tes priorités de vie.
|
||||||
|
|
||||||
|
- Le couple est revenu trois fois en coaching. Ce n'est pas un hasard. C'est ton système qui te dit : "Écoute, je sais que tu sais que c'est important. Pourrais-tu maintenant faire quelque chose au lieu de le savoir ?"
|
||||||
|
|
||||||
|
- Le fait que tu aies créé des veilles et des playbooks en une semaine, sans revue hebdo consolidée des OKRs, c'est révélateur : tu aimes bâtir les outillages. Mais le vrai travail est dans l'utilisation quotidienne, le micro-rituel, le "petit truc" non-sexy. Là, tu n'es pas au meilleur de toi-même.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Ta réflexion
|
||||||
|
|
||||||
|
<!-- Espace libre — réponds à ce qui résonne, pas à tout -->
|
||||||
216
10-projects/ameno/mantis-ticket-skill-export.md
Normal file
216
10-projects/ameno/mantis-ticket-skill-export.md
Normal file
|
|
@ -0,0 +1,216 @@
|
||||||
|
# Mantis Story Ticket Generator - Skill Documentation
|
||||||
|
|
||||||
|
## Métadonnées du Skill
|
||||||
|
|
||||||
|
- **Nom:** mantis-ticket
|
||||||
|
- **Description:** Generate well-structured Mantis bug tracking tickets in story format from user requirements. Use when the user requests ticket creation, bug report formatting, or needs to transform requirements into Mantis-compatible JSON. Produces narrative-style tickets that are human and AI readable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mantis Story Ticket Generator
|
||||||
|
|
||||||
|
Generate professional Mantis tickets with a narrative, story-driven style that's easy to understand for both humans and AI.
|
||||||
|
|
||||||
|
## Output Format
|
||||||
|
|
||||||
|
Always produce a JSON array containing one or more ticket objects:
|
||||||
|
|
||||||
|
```json
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"summary": "Clear, action-oriented title",
|
||||||
|
"description": "Story-formatted description using Mantis BBCode tags"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Story Writing Principles
|
||||||
|
|
||||||
|
**Narrative tone**: Write as if explaining the ticket to a colleague, not a robot
|
||||||
|
- Use natural language flow
|
||||||
|
- Connect ideas with context
|
||||||
|
- Explain the "why" not just the "what"
|
||||||
|
|
||||||
|
**Be concrete and specific**:
|
||||||
|
- Avoid vague terms like "improve", "optimize", "enhance"
|
||||||
|
- Use real examples and scenarios
|
||||||
|
- Include actual values, screens, or user actions when relevant
|
||||||
|
|
||||||
|
**Structure with purpose**:
|
||||||
|
- Each section should tell part of the story
|
||||||
|
- Start with context (where are we?)
|
||||||
|
- Move to action (what needs to happen?)
|
||||||
|
- End with validation (how do we know it's done?)
|
||||||
|
|
||||||
|
## Mantis BBCode Tags
|
||||||
|
|
||||||
|
**ONLY use these tags** (Mantis-compatible):
|
||||||
|
- `[b]text[/b]` - Bold text
|
||||||
|
- `[list][*] item[/list]` - Bullet lists (always use `[*]` inside `[list]`)
|
||||||
|
|
||||||
|
**NEVER use**: Markdown, HTML, hyphens for lists, asterisks outside `[list]`
|
||||||
|
|
||||||
|
## Description Structure
|
||||||
|
|
||||||
|
Use these sections in order (omit non-relevant sections for simple tickets):
|
||||||
|
|
||||||
|
### [b]Contexte[/b]
|
||||||
|
Paint the picture: Where are we? What's the current situation? Why does this matter?
|
||||||
|
|
||||||
|
Example:
|
||||||
|
```
|
||||||
|
Actuellement, les utilisateurs doivent copier-coller manuellement les informations d'un email vers Mantis pour créer un ticket. Cette tâche répétitive prend environ 5 minutes par ticket et génère des erreurs de saisie.
|
||||||
|
```
|
||||||
|
|
||||||
|
### [b]À faire[/b]
|
||||||
|
What needs to happen? Describe the journey from current to desired state.
|
||||||
|
|
||||||
|
Use `[list][*]` for action items:
|
||||||
|
```
|
||||||
|
[list]
|
||||||
|
[*] Ajouter un bouton "Créer ticket" dans le ruban Outlook
|
||||||
|
[*] Extraire automatiquement le sujet de l'email comme titre du ticket
|
||||||
|
[*] Pré-remplir la description avec le corps de l'email
|
||||||
|
[/list]
|
||||||
|
```
|
||||||
|
|
||||||
|
### [b]Règles / Détails[/b]
|
||||||
|
Important constraints, business rules, or technical details that guide implementation.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
```
|
||||||
|
Le bouton doit être visible uniquement quand un email est sélectionné. Si l'email contient des pièces jointes, proposer de les inclure comme screenshots dans le ticket.
|
||||||
|
```
|
||||||
|
|
||||||
|
### [b]Critères de validation[/b]
|
||||||
|
How do we know it's done? Describe the success scenario.
|
||||||
|
|
||||||
|
```
|
||||||
|
[list]
|
||||||
|
[*] Un utilisateur peut sélectionner un email et cliquer sur "Créer ticket"
|
||||||
|
[*] Le ticket apparaît dans Mantis avec le bon projet et les bonnes informations
|
||||||
|
[*] Le temps de création passe de 5 minutes à moins de 30 secondes
|
||||||
|
[/list]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Content Rules
|
||||||
|
|
||||||
|
**Ask questions when information is missing**:
|
||||||
|
- Title unclear? Ask for a concrete action verb
|
||||||
|
- Requirements vague? Request specific examples
|
||||||
|
- Multiple unrelated tasks? Confirm if they should be separate tickets
|
||||||
|
|
||||||
|
**Multiple independent requests**: Generate separate tickets, each with its own summary and description
|
||||||
|
|
||||||
|
**Keep it concise**:
|
||||||
|
- Short, factual sentences
|
||||||
|
- No invented information
|
||||||
|
- Skip sections that don't add value
|
||||||
|
|
||||||
|
## What NOT to Do
|
||||||
|
|
||||||
|
- Never explain your process or add meta-commentary
|
||||||
|
- Never include field names like "Projet:" or "Priorité:" in the output
|
||||||
|
- Never add sections beyond the four standard ones
|
||||||
|
- Never use Markdown syntax or HTML tags
|
||||||
|
- Never use hyphens or standalone asterisks for lists
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Exemples de Tickets Mantis en Mode Story
|
||||||
|
|
||||||
|
Ce document contient des exemples de tickets bien formatés qui illustrent l'approche narrative recommandée.
|
||||||
|
|
||||||
|
## Exemple 1 : Ticket Simple (Sections Minimales)
|
||||||
|
|
||||||
|
**User request:** "Il faut ajouter un bouton d'export CSV sur la liste des utilisateurs"
|
||||||
|
|
||||||
|
```json
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"summary": "Ajouter l'export CSV sur la liste des utilisateurs",
|
||||||
|
"description": "[b]Contexte[/b]\nLes administrateurs consultent régulièrement la liste des utilisateurs dans le backoffice pour faire des analyses. Actuellement, ils doivent copier-coller manuellement les données dans Excel, ce qui est fastidieux et source d'erreurs quand il y a plus de 50 utilisateurs.\n\n[b]À faire[/b]\n[list]\n[*] Ajouter un bouton \"Exporter en CSV\" au-dessus du tableau des utilisateurs\n[*] Le fichier CSV doit contenir toutes les colonnes visibles : nom, email, date d'inscription, statut\n[*] Le nom du fichier doit suivre le format : utilisateurs_YYYY-MM-DD.csv\n[/list]\n\n[b]Critères de validation[/b]\n[list]\n[*] Le bouton est visible et cliquable par tous les administrateurs\n[*] Le téléchargement du CSV démarre immédiatement au clic\n[*] Le fichier s'ouvre correctement dans Excel avec l'encodage UTF-8\n[/list]"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Exemple 2 : Ticket Complexe (Toutes les Sections)
|
||||||
|
|
||||||
|
**User request:** "On a besoin d'améliorer le système de notifications pour les tickets urgents"
|
||||||
|
|
||||||
|
```json
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"summary": "Implémenter les notifications temps réel pour les tickets urgents",
|
||||||
|
"description": "[b]Contexte[/b]\nActuellement, les développeurs ne découvrent les tickets marqués comme \"urgents\" que lorsqu'ils consultent manuellement Mantis. Cela crée des délais de réaction pouvant aller jusqu'à plusieurs heures, ce qui est problématique pour les incidents de production.\n\n[b]À faire[/b]\n[list]\n[*] Envoyer un email immédiat aux développeurs assignés quand un ticket passe en priorité \"urgente\"\n[*] Afficher une notification dans l'interface web Mantis si l'utilisateur est connecté\n[*] Inclure dans la notification : titre du ticket, nom du projet, et lien direct vers le ticket\n[/list]\n\n[b]Règles / Détails[/b]\nLes notifications ne doivent être envoyées que pendant les heures ouvrables (9h-18h du lundi au vendredi). En dehors de ces horaires, les tickets urgents sont mis en file d'attente et les notifications sont envoyées dès 9h le jour ouvrable suivant. Exception : les tickets du projet \"Production\" déclenchent toujours une notification immédiate, même le week-end.\n\n[b]Critères de validation[/b]\n[list]\n[*] Un développeur reçoit l'email dans les 2 minutes suivant le passage en \"urgent\"\n[*] La notification web apparaît instantanément si le développeur est connecté\n[*] Aucune notification n'est envoyée en dehors des heures ouvrables (sauf projet Production)\n[*] Le lien dans l'email mène directement au ticket concerné\n[/list]"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Exemple 3 : Requêtes Multiples (Plusieurs Tickets)
|
||||||
|
|
||||||
|
**User request:** "Il faut corriger le bug d'affichage des dates et aussi ajouter une recherche par statut"
|
||||||
|
|
||||||
|
```json
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"summary": "Corriger l'affichage des dates au format FR",
|
||||||
|
"description": "[b]Contexte[/b]\nLes dates s'affichent actuellement au format US (MM/DD/YYYY) dans l'interface, ce qui crée de la confusion pour nos utilisateurs français qui attendent le format JJ/MM/AAAA.\n\n[b]À faire[/b]\n[list]\n[*] Modifier le format d'affichage des dates en JJ/MM/AAAA partout dans l'interface\n[*] Vérifier que les dates de création, modification et échéance sont toutes concernées\n[/list]\n\n[b]Critères de validation[/b]\n[list]\n[*] Toutes les dates affichées respectent le format JJ/MM/AAAA\n[*] Le tri par date fonctionne toujours correctement\n[/list]"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"summary": "Ajouter un filtre de recherche par statut de ticket",
|
||||||
|
"description": "[b]Contexte[/b]\nLes utilisateurs doivent actuellement parcourir manuellement la liste complète des tickets pour identifier ceux dans un statut particulier (nouveau, en cours, résolu, etc.). Avec plus de 200 tickets dans certains projets, cette recherche manuelle devient chronophage.\n\n[b]À faire[/b]\n[list]\n[*] Ajouter un menu déroulant \"Filtrer par statut\" au-dessus de la liste des tickets\n[*] Inclure tous les statuts possibles : nouveau, assigné, résolu, fermé, rejeté\n[*] Ajouter une option \"Tous les statuts\" pour désactiver le filtre\n[/list]\n\n[b]Critères de validation[/b]\n[list]\n[*] La sélection d'un statut filtre instantanément la liste affichée\n[*] Le nombre de tickets affichés correspond au statut sélectionné\n[*] Le filtre peut être combiné avec la recherche textuelle existante\n[/list]"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Exemple 4 : Ticket Technique avec Détails Spécifiques
|
||||||
|
|
||||||
|
**User request:** "L'API REST renvoie une erreur 500 quand on essaie de créer un ticket avec une pièce jointe de plus de 5MB"
|
||||||
|
|
||||||
|
```json
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"summary": "Gérer les pièces jointes volumineuses dans l'API REST",
|
||||||
|
"description": "[b]Contexte[/b]\nL'API REST actuelle de Mantis retourne une erreur 500 (Internal Server Error) lorsqu'un utilisateur tente de créer un ticket avec une pièce jointe supérieure à 5MB. Cette limite n'est documentée nulle part et l'erreur n'est pas explicite, ce qui complique le débogage pour les développeurs qui intègrent l'API.\n\n[b]À faire[/b]\n[list]\n[*] Augmenter la limite de taille des pièces jointes à 20MB dans la configuration du serveur\n[*] Retourner une erreur 413 (Payload Too Large) avec un message explicite si la limite est dépassée\n[*] Documenter cette limite dans la documentation de l'API REST\n[/list]\n\n[b]Règles / Détails[/b]\nLe message d'erreur doit être en JSON et contenir : le code d'erreur (413), un message clair (\"File size exceeds 20MB limit\"), et la taille maximale autorisée. Le header Content-Type doit rester application/json même en cas d'erreur.\n\n[b]Critères de validation[/b]\n[list]\n[*] Les pièces jointes jusqu'à 20MB sont acceptées et attachées correctement au ticket\n[*] Les fichiers > 20MB génèrent une erreur 413 avec un message JSON explicite\n[*] La documentation API mentionne cette limite de 20MB\n[*] Les tests unitaires couvrent les cas limites (19.9MB, 20MB, 20.1MB)\n[/list]"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Bonnes Pratiques Illustrées
|
||||||
|
|
||||||
|
### Ton Narratif
|
||||||
|
❌ **Mauvais** : "Ajouter fonctionnalité export"
|
||||||
|
✅ **Bon** : "Les administrateurs consultent régulièrement la liste... ils doivent copier-coller..."
|
||||||
|
|
||||||
|
### Spécificité
|
||||||
|
❌ **Mauvais** : "Améliorer les performances"
|
||||||
|
✅ **Bon** : "Réduire le temps de chargement de 3 secondes à moins de 1 seconde"
|
||||||
|
|
||||||
|
### Contexte Significatif
|
||||||
|
❌ **Mauvais** : "Bug d'affichage"
|
||||||
|
✅ **Bon** : "Les dates s'affichent au format US, ce qui crée de la confusion pour nos utilisateurs français"
|
||||||
|
|
||||||
|
### Critères Mesurables
|
||||||
|
❌ **Mauvais** : "Ça doit bien fonctionner"
|
||||||
|
✅ **Bon** : "Le développeur reçoit l'email dans les 2 minutes", "Le fichier s'ouvre dans Excel"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Installation du Skill
|
||||||
|
|
||||||
|
Pour utiliser ce skill dans Claude:
|
||||||
|
|
||||||
|
1. Créer la structure de dossiers:
|
||||||
|
```
|
||||||
|
mantis-ticket/
|
||||||
|
├── SKILL.md (contenu principal)
|
||||||
|
└── references/
|
||||||
|
└── examples.md (exemples détaillés)
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Copier le contenu approprié dans chaque fichier
|
||||||
|
|
||||||
|
3. Packager avec: `scripts/package_skill.py mantis-ticket/`
|
||||||
|
|
||||||
|
4. Importer le fichier `.skill` généré dans Claude
|
||||||
BIN
10-projects/ameno/mantis-ticket.skill
Normal file
BIN
10-projects/ameno/mantis-ticket.skill
Normal file
Binary file not shown.
191
10-projects/gesteos/support-gesteos.md
Normal file
191
10-projects/gesteos/support-gesteos.md
Normal file
|
|
@ -0,0 +1,191 @@
|
||||||
|
---
|
||||||
|
statut: idée
|
||||||
|
role: seenaps
|
||||||
|
objectif: Industrialiser le support client Gesteos avec l'IA
|
||||||
|
echeance:
|
||||||
|
okr:
|
||||||
|
---
|
||||||
|
|
||||||
|
# IA pour le support client Gesteos
|
||||||
|
|
||||||
|
## Résultat attendu
|
||||||
|
|
||||||
|
Mettre en place un dispositif d'assistance IA pour réduire la charge support, homogénéiser les réponses et capitaliser automatiquement la connaissance issue des tickets Gesteos.
|
||||||
|
|
||||||
|
## Pourquoi ce projet
|
||||||
|
|
||||||
|
Le support Gesteos est aujourd'hui fortement dépendant des personnes, coûteux en temps humain et peu capitalisé. L'IA peut transformer chaque ticket traité en connaissance réutilisable, tout en accélérant la montée en compétence du support N1.
|
||||||
|
|
||||||
|
## Problème actuel
|
||||||
|
|
||||||
|
Aujourd'hui, le support est :
|
||||||
|
|
||||||
|
- fortement consommateur de temps humain, notamment en N1 et N2 ;
|
||||||
|
- peu capitalisé, avec des réponses souvent répétées ;
|
||||||
|
- dépendant des individus, notamment Boris et Sylvie ;
|
||||||
|
- hétérogène en qualité et en délai.
|
||||||
|
|
||||||
|
Conséquences directes :
|
||||||
|
|
||||||
|
- coût support élevé ;
|
||||||
|
- montée en compétence lente pour Tony et les futurs recrutements ;
|
||||||
|
- pression sur le BUILD, notamment Fred ;
|
||||||
|
- expérience client variable.
|
||||||
|
|
||||||
|
## Principe du cas d'usage
|
||||||
|
|
||||||
|
Utiliser Claude AI comme moteur de capitalisation et d'assistance au support.
|
||||||
|
|
||||||
|
L'IA serait alimentée par :
|
||||||
|
|
||||||
|
- les tickets historiques Odoo ;
|
||||||
|
- les réponses support existantes ;
|
||||||
|
- la documentation produit : release notes, guides, aide en ligne ;
|
||||||
|
- les bonnes pratiques internes.
|
||||||
|
|
||||||
|
Objectif : transformer chaque ticket traité en connaissance réutilisable.
|
||||||
|
|
||||||
|
## Fonctionnement cible
|
||||||
|
|
||||||
|
### 1. Analyse automatique du ticket
|
||||||
|
|
||||||
|
Quand un ticket arrive, l'IA identifie :
|
||||||
|
|
||||||
|
- le type de problème : facturation, liaison InSitu, etc. ;
|
||||||
|
- la fréquence : problème connu ou nouveau ;
|
||||||
|
- le niveau : N1 ou N2.
|
||||||
|
|
||||||
|
Résultats attendus :
|
||||||
|
|
||||||
|
- pré-qualification automatique ;
|
||||||
|
- gain de temps immédiat.
|
||||||
|
|
||||||
|
### 2. Proposition de réponse
|
||||||
|
|
||||||
|
L'IA génère :
|
||||||
|
|
||||||
|
- un diagnostic ;
|
||||||
|
- une checklist de vérification ;
|
||||||
|
- une réponse client prête à envoyer.
|
||||||
|
|
||||||
|
Exemple de réponse type :
|
||||||
|
|
||||||
|
> Avez-vous vérifié X / Y / Z ?
|
||||||
|
|
||||||
|
Le support :
|
||||||
|
|
||||||
|
- valide ou ajuste la proposition ;
|
||||||
|
- envoie la réponse au client.
|
||||||
|
|
||||||
|
Gains attendus :
|
||||||
|
|
||||||
|
- moins de rédaction manuelle ;
|
||||||
|
- réponses plus homogènes.
|
||||||
|
|
||||||
|
### 3. Capitalisation automatique
|
||||||
|
|
||||||
|
Chaque ticket traité enrichit une fiche support structurée :
|
||||||
|
|
||||||
|
- symptôme ;
|
||||||
|
- cause ;
|
||||||
|
- résolution ;
|
||||||
|
- réponse type.
|
||||||
|
|
||||||
|
Effets cumulés :
|
||||||
|
|
||||||
|
- amélioration continue ;
|
||||||
|
- base de connaissance vivante.
|
||||||
|
|
||||||
|
### 4. Assistance proactive
|
||||||
|
|
||||||
|
À terme, le système peut permettre :
|
||||||
|
|
||||||
|
- des suggestions en temps réel au support ;
|
||||||
|
- la détection de patterns récurrents ;
|
||||||
|
- des alertes sur les bugs fréquents à remonter au BUILD.
|
||||||
|
|
||||||
|
Impact clé : Boris passe progressivement de l'exécution du support au pilotage du système.
|
||||||
|
|
||||||
|
### 5. Self-service client
|
||||||
|
|
||||||
|
En phase avancée, le client pourrait :
|
||||||
|
|
||||||
|
- poser une question directement ;
|
||||||
|
- recevoir une réponse IA basée sur la base support.
|
||||||
|
|
||||||
|
Objectif : éviter la création de tickets lorsque le cas est connu et maîtrisé.
|
||||||
|
|
||||||
|
## Cas concret : liaison InSitu
|
||||||
|
|
||||||
|
Situation actuelle :
|
||||||
|
|
||||||
|
- 10 tickets similaires ;
|
||||||
|
- 10 réponses manuelles.
|
||||||
|
|
||||||
|
Situation cible avec IA :
|
||||||
|
|
||||||
|
- Claude identifie le pattern ;
|
||||||
|
- propose une réponse standard ;
|
||||||
|
- guide le client avec une checklist ;
|
||||||
|
- résout 60 % des cas sans intervention humaine.
|
||||||
|
|
||||||
|
## Impacts attendus
|
||||||
|
|
||||||
|
### Court terme : 1 à 2 mois
|
||||||
|
|
||||||
|
- Réduction de 30 % du temps de réponse support.
|
||||||
|
- Homogénéisation des réponses.
|
||||||
|
- Montée en compétence accélérée des juniors.
|
||||||
|
|
||||||
|
### Moyen terme : 3 à 6 mois
|
||||||
|
|
||||||
|
- 50 à 60 % des tickets assistés ou résolus par IA.
|
||||||
|
- Réduction de la charge N2 pour Boris.
|
||||||
|
- Moins de sollicitations pour Fred.
|
||||||
|
|
||||||
|
### Long terme : 6 à 12 mois
|
||||||
|
|
||||||
|
- Self-service client partiel.
|
||||||
|
- Support plus scalable.
|
||||||
|
- Capacité libérée pour :
|
||||||
|
- le commerce ;
|
||||||
|
- l'onboarding ;
|
||||||
|
- la delivery.
|
||||||
|
|
||||||
|
## Impacts organisationnels
|
||||||
|
|
||||||
|
### Delivery
|
||||||
|
|
||||||
|
- Boris devient pilote du système plutôt qu'exécutant principal.
|
||||||
|
- Le N1 est augmenté par l'IA : Tony et futurs recrutements.
|
||||||
|
|
||||||
|
### Build
|
||||||
|
|
||||||
|
- Moins de bruit support.
|
||||||
|
- Meilleure remontée des vrais bugs.
|
||||||
|
|
||||||
|
### Growth
|
||||||
|
|
||||||
|
- Temps libéré pour Sylvie.
|
||||||
|
- Meilleure expérience client, donc meilleure conversion potentielle.
|
||||||
|
|
||||||
|
## Points à challenger
|
||||||
|
|
||||||
|
- Qualité et accessibilité des données Odoo : les tickets historiques sont-ils exploitables sans nettoyage massif ?
|
||||||
|
- Responsabilité de validation : qui arbitre entre réponse IA, réponse support et correction produit ?
|
||||||
|
- Risque de masquer des bugs récurrents si l'IA absorbe trop bien les symptômes.
|
||||||
|
- ROI réel : les gains annoncés doivent être mesurés sur un périmètre pilote avant généralisation.
|
||||||
|
|
||||||
|
## Prochaine action
|
||||||
|
|
||||||
|
- Définir un pilote limité sur un cas fréquent, par exemple la liaison InSitu, avec un objectif mesurable de réduction du temps de traitement.
|
||||||
|
|
||||||
|
## Notes et avancement
|
||||||
|
|
||||||
|
### 2026-05-09
|
||||||
|
|
||||||
|
- Formalisation du cas d'usage IA pour le support client Gesteos.
|
||||||
|
|
||||||
|
## Source
|
||||||
|
|
||||||
|
Note issue d'un échange avec Stéphane Trémier, CEO 6TM.
|
||||||
Binary file not shown.
BIN
10-projects/seenaps-financial/rh/ANNE Yannick - Liasse 2025.pdf
Normal file
BIN
10-projects/seenaps-financial/rh/ANNE Yannick - Liasse 2025.pdf
Normal file
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN
10-projects/seenaps-financial/rh/Bilan Cuisines Bretagne Sud.pdf
Normal file
BIN
10-projects/seenaps-financial/rh/Bilan Cuisines Bretagne Sud.pdf
Normal file
Binary file not shown.
Binary file not shown.
BIN
10-projects/seenaps-financial/rh/GEM d analyse de bilans.docx
Normal file
BIN
10-projects/seenaps-financial/rh/GEM d analyse de bilans.docx
Normal file
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
3
10-projects/seenaps-financial/seenaps-financial.md
Normal file
3
10-projects/seenaps-financial/seenaps-financial.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
## indicateurs sectoriels
|
||||||
|
Voir l'intégrationd d'indicateur sectoriels ?
|
||||||
|
https://www.banque-france.fr/fr/publications-et-statistiques/statistiques/fascicules-dindicateurs-sectoriels
|
||||||
|
|
@ -0,0 +1,132 @@
|
||||||
|
# Compte rendu — Atelier Analyse bilancielle Transakauto
|
||||||
|
|
||||||
|
**Date :** 30/04/2026
|
||||||
|
**Type :** Atelier
|
||||||
|
**Participants :**
|
||||||
|
- Blanche (Transakauto, tête de réseau)
|
||||||
|
- Guillaume B. (Expert-comptable)
|
||||||
|
- Philippe A. (Seenaps / 6TM)
|
||||||
|
- Quentin B. (6TM)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Cadrage : public cible et objectif
|
||||||
|
|
||||||
|
La fonctionnalité d'analyse bilancielle est destinée à la **tête de réseau**, plus précisément aux animatrices, qui ne sont pas formées à la lecture d'un bilan. L'objectif n'est pas une analyse financière fine mais un système d'alerte simple permettant d'identifier rapidement les franchisés en difficulté.
|
||||||
|
|
||||||
|
Constat de Blanche : un franchisé qui va bien le dit, un franchisé en difficulté minimise. La fonctionnalité doit compenser ce biais déclaratif via la donnée comptable. Guillaume confirme l'enjeu : certains arbitrages comptables de clôture (abandon de dettes, produit exceptionnel) peuvent masquer une situation difficile et restent illisibles pour un non-comptable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Source documentaire : liasse fiscale
|
||||||
|
|
||||||
|
La source retenue est la **liasse fiscale**, normée réglementairement (chaque case porte un numéro standardisé). Les plaquettes comptables varient trop selon les logiciels (Sage, Sejid, ACD, Pennylane, My Company Soft) pour être exploitables de manière homogène.
|
||||||
|
|
||||||
|
Deux types existent (simplifiée et réelle selon les seuils), mais les deux exposent les grands indicateurs nécessaires : CA, trésorerie, capitaux propres, résultat net. La liasse ne permet pas de descendre au niveau du loyer ou du détail des charges, ce qui est jugé suffisant pour le besoin animateur.
|
||||||
|
|
||||||
|
Les situations intermédiaires (en cours d'année) ne sont pas couvertes : elles font l'objet d'une plaquette des comptes non normée, et l'obligation contractuelle franchiseur ne porte que sur la transmission annuelle du bilan.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Ratios et logique de notation
|
||||||
|
|
||||||
|
Principe retenu : un nombre limité d'indicateurs, chacun qualifié par une note (A/B/C/D) ou un pictogramme (rouge/vert, smileys gradués). A/B = situation correcte, C/D = alerte qui remonte à la directrice réseau pour décision d'un point de suivi.
|
||||||
|
|
||||||
|
Pour chaque indicateur, deux références complémentaires : la cible du panel et la valeur réelle du panel. Si possible, une note moyenne globale synthétisant l'ensemble. Guillaume apportera des **commentaires ponctuels** sur certaines cases pour expliciter les arbitrages comptables.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Timing de récupération
|
||||||
|
|
||||||
|
Cible opérationnelle : **bilan disponible 4 mois après la clôture** (le réglementaire est 15 mai pour clôture 31/12, 3,5 mois pour les clôtures décalées). Délai jugé acceptable pour le rythme d'animation.
|
||||||
|
|
||||||
|
Les clôtures Transakauto sont étalées sur l'année. Cet étalement devra être pris en compte côté Seenaps pour ne pas mélanger des éléments annuels avec du mensuel dans les comparaisons de panel.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Croisement avec d'autres KPIs
|
||||||
|
|
||||||
|
Pistes évoquées :
|
||||||
|
- **CA / nombre de véhicules** : non représentatif (autres activités possibles, détail CA absent de la liasse).
|
||||||
|
- **CA / m²** : non pertinent vu la diversité des formats d'agences Transakauto.
|
||||||
|
- **CA / ancienneté de l'agence** : piste retenue (analogie carnet de santé — comparer à stade de maturité comparable).
|
||||||
|
- **Croisement avec les visites / actions non réalisées Seenaps** : piste à approfondir (Quentin).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Profondeur historique
|
||||||
|
|
||||||
|
Conserver **2 années** : 2024 et 2025. Le contrat de franchise a été signé début 2025, mais 2024 (sous contrat de licence) garde de la valeur pour détecter un passif antérieur à apurer. À partir de 2027, la comparaison se fera 2025 vs 2026 et le millésime 2024 sortira.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Restitution animateur
|
||||||
|
|
||||||
|
Vue agrégée par franchisé avec indicateurs limités et lisibles (vert/rouge ou équivalent), cible et valeur du panel, et idéalement une note moyenne globale.
|
||||||
|
|
||||||
|
**Demande Blanche** : afficher la note bilancielle **à côté de la météo** déjà existante dans Seenaps, pour que l'animateur puisse prioriser ses tournées en s'appuyant sur cette donnée.
|
||||||
|
|
||||||
|
Philippe confirme que ces analyses sont des KPIs comme les autres dans la plateforme, donc paramétrables côté affichage. Le travail de fond porte sur le détail des calculs.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Module de relance des bilans
|
||||||
|
|
||||||
|
La récupération des bilans est aujourd'hui difficile. La date de clôture est saisie au format `31-12` sans année dans Seenaps, ce qui empêche toute relance automatique.
|
||||||
|
|
||||||
|
**Demande** : générer automatiquement un email de relance au franchisé 3 mois après sa clôture. Philippe confirme qu'un **module dédié sera structuré** pour cette partie, et que la zone documentaire de dépôt sera **restructurée** (Blanche signale aujourd'hui un problème de permissions empêchant les franchisés de déposer eux-mêmes leur bilan).
|
||||||
|
|
||||||
|
Suggestion de Guillaume (retour d'expérience d'autres réseaux) : conditionner l'éligibilité aux challenges et animations à la transmission des états financiers, comme pour le paiement des redevances.
|
||||||
|
|
||||||
|
**Saisonnalité** : non applicable à Transakauto (activité linéaire selon Guillaume), donc la date de clôture n'aura pas d'incidence et on pourra compiler 12 mois glissants même si ce ne sont pas exactement les mêmes 12 mois d'un franchisé à l'autre.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Cas multi-agences : non traité
|
||||||
|
|
||||||
|
Guillaume soulève le cas où plusieurs agences seraient regroupées dans une même société (bilan agrégé qui fausse l'analyse). Blanche confirme que **ce cas n'est pas autorisé contractuellement** (1 société = 1 zone). Un cas existait dans le réseau, découvert la veille — traité en interne par Blanche.
|
||||||
|
|
||||||
|
**Décision** : aucun développement spécifique. Seenaps est de toute façon structuré par agence, la société étant uniquement informative. Le module de relance devra simplement éviter la duplication si plusieurs agences sont rattachées au même franchisé.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Recoupements bilan / TVA / ERP / Seenaps
|
||||||
|
|
||||||
|
La redevance Transakauto est calculée sur les déclarations de TVA, mais le CA déclaré n'est pas systématiquement réel. Avec le **lancement de l'ERP la semaine suivante**, la facturation remontera automatiquement vers Seenaps puis vers Pennylane.
|
||||||
|
|
||||||
|
Guillaume valide le besoin de **trois recoupements** :
|
||||||
|
1. CA issu du nouvel ERP
|
||||||
|
2. CA issu des déclarations de TVA (base actuelle des redevances)
|
||||||
|
3. CA issu du bilan in fine
|
||||||
|
|
||||||
|
Ce triple recoupement permet de détecter une éventuelle alimentation du CA hors Seenaps. Quentin confirme que les franchisés Transakauto n'ont pas le droit de mener une autre activité sous la même société.
|
||||||
|
|
||||||
|
**TVA** : transmise mensuellement par les franchisés. Mécanisme actuel défaillant côté Seenaps (1 dépôt sur 2 échoue, vraisemblablement un sujet de permissions). Demande de Blanche en cours pour permettre le dépôt direct par le franchisé dans son dossier.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. Calcul des redevances : situation actuelle et cible
|
||||||
|
|
||||||
|
**Aujourd'hui (manuel)** : récupération de la déclaration de TVA → alimentation Excel → application formule (avec seuil minimum) → envoi à Pennylane.
|
||||||
|
|
||||||
|
**À court terme (ERP)** : remontée automatique vers Seenaps puis Pennylane pour facturation.
|
||||||
|
|
||||||
|
Blanche souhaite **conserver la double vérification** via la déclaration de TVA même en mode automatisé, comme garde-fou.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Récapitulatif des actions
|
||||||
|
|
||||||
|
| Action | Responsable | Échéance |
|
||||||
|
|---|---|---|
|
||||||
|
| Définir la liste des ratios financiers et les seuils de notation (A/B/C/D) | Guillaume B. | À définir |
|
||||||
|
| Préparer les commentaires / points d'attention sur certaines cases de la liasse | Guillaume B. | À définir |
|
||||||
|
| Spécifier le mécanisme cible / valeur réelle par panel pour chaque indicateur | 6TM | À définir |
|
||||||
|
| Spécifier le module de relance automatique (3 mois post-clôture) | 6TM | À définir |
|
||||||
|
| Restructurer la zone documentaire (dépôt bilan + TVA) et corriger les permissions franchisé | 6TM | À définir |
|
||||||
|
| Étudier le croisement avec les KPIs visites / actions non réalisées | Quentin B. | À définir |
|
||||||
|
| Définir l'affichage de la note bilancielle à côté de la météo | 6TM | À définir |
|
||||||
|
| Régulariser le cas franchisé en infraction au principe « 1 société = 1 zone » | Blanche | En cours |
|
||||||
|
| Évaluer l'intégration de la transmission du bilan comme critère d'éligibilité aux challenges | Blanche | À définir |
|
||||||
|
| Lancer l'ERP (alimentation Seenaps + Pennylane) | Transakauto / 6TM | Semaine du 04/05/2026 |
|
||||||
|
| Confirmer la date de rendu / jalon suivant (mail Olifant) | Guillaume B. | 18/05/2026 |
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
170
10-projects/seenaps/northStar/northStar.md
Normal file
170
10-projects/seenaps/northStar/northStar.md
Normal file
|
|
@ -0,0 +1,170 @@
|
||||||
|
## Gaetan
|
||||||
|
J’ai centré ma réflexion sur nos modules clés (animation, cockpit/CRM) avec les personas clés que sont l’animateur et le dirigeant ou le directeur de réseau.
|
||||||
|
|
||||||
|
Dans cette perspective je retiendrai comme NSM :
|
||||||
|
Le taux de PDV avec un plan d'action actif et suivi
|
||||||
|
ou si on veut aller plus sur la perf
|
||||||
|
Le taux d’actions complétés par le réseau (et par PDV).
|
||||||
|
|
||||||
|
Quelques KPIs en lien avec cette NSM
|
||||||
|
Nombre de PDV pilotés par animateur.
|
||||||
|
Taux d’actions prioritaires clôturées (avant leur échéance, à leur échéance, après leur échéance).
|
||||||
|
Délai moyen de traitement des actions prioritaires.
|
||||||
|
|
||||||
|
Autres KPIs plus orientés global Seenaps
|
||||||
|
Sur l’usage > nombre et taux d’utilisateurs actif par semaine.
|
||||||
|
Sur le business > Le MRR net pour un suivi hebdo/mensuel. Le MRR net étant = new MRR + upsell/crosell MRR - churent MRR.
|
||||||
|
|
||||||
|
## Aurélie
|
||||||
|
Bonjour Philippe,
|
||||||
|
|
||||||
|
Ci-dessous mon retour.
|
||||||
|
Je propose 2 North Star Metric. La première avec des KPIs plus orientés usage et la seconde avec des KPIs plus orientés produit.
|
||||||
|
|
||||||
|
North Star Metric : Taux de contributeurs / module (-> montre le pilotage du réseau et la relation entre le siège et les points de vente et également l'utilisation des différentes fonctionnalités des 2 côtés)
|
||||||
|
|
||||||
|
KPIs à suivre :
|
||||||
|
Pourcentage/nombre d'utilisateurs terrain (au sein des points de ventes) ayant généré X actions de création (un commentaire, une saisie de KPI, lecture des documents, actu...) sur le mois écoulé.
|
||||||
|
Pourcentage/nombre d'utilisateurs siège (au sein de la tête de réseau) ayant généré X actions de création (resp communication : nombre d'actu publiées; chargé de développement : nombre de candidatures ajoutées/traitées par développeur...) sur le mois écoulé.
|
||||||
|
Taux de récurrence des contributeurs : pourcentage de contributeurs qui contribuent régulièrement dans le temps (voir les comportements)
|
||||||
|
(Ratio entre les contributions provenant du terrain et les contributions provenant du siège (publications d'actu, ...).)
|
||||||
|
|
||||||
|
|
||||||
|
2- North Star Metric : Taux de fonctionnalités à forte valeur adoptées (adoptées de manière complète, utilisées de manière récurrente et avec un impact mesurable)
|
||||||
|
|
||||||
|
KPIs à suivre :
|
||||||
|
Taux d’adoption "profonde" par fonctionnalité (pourcentage d’utilisateurs qui utilisent une fonctionnalité "clé" de manière complète et répétée) (ex: créer une actu -> publier régulièrement -> consulter les stats -> interagir avec le contenu)
|
||||||
|
Taux de dépendance fonctionnelle/récurrence (pourcentage d’utilisateurs pour qui la fonctionnalité est devenue indispensable) (fréquence d’usage élevée, usage régulier dans le temps...)
|
||||||
|
Impact perçu / réel par fonctionnalité (Est-ce que la fonctionnalité améliore concrètement quelque chose ?) (ex: Développement : temps de traitement des leads en baisse, taux de conversion en hausse ; Animation : % d'actions réalisées...; Communication : taux de lecture...; meilleure structuration...Ce KPI peut aussi être mesuré par des enquêtes notamment NPS)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Surveiller aussi le pourcentage d'utilisateurs qui se connectent (logs) mais ne contribuent jamais (levier de croissance)
|
||||||
|
Regarder les stats actuelles pour mettre les curseurs des taux à atteindre, du nombre d'actions...
|
||||||
|
|
||||||
|
## Bastien
|
||||||
|

|
||||||
|
|
||||||
|
Salut Philippe,
|
||||||
|
|
||||||
|
Suite à ton mail concernant la réflexion sur les KPIs et la North Star, je te partage une proposition que j'ai mis en place chez Steeple, avec des indicateurs différents, mais la logique reste la même dans les grandes lignes.
|
||||||
|
|
||||||
|
Cela nous avait permis de changer trois gros sujets :
|
||||||
|
La perception du client sur l'usage du produit
|
||||||
|
La stratégie produit pour développer des fonctionnalités qui améliore réellement l'usage
|
||||||
|
La stratégie commerciale pour avoir le bon discours auprès de la bonne cible
|
||||||
|
|
||||||
|
🎯 1. Point de départ : que doit-on réellement mesurer ?
|
||||||
|
Seenaps n’est pas un outil de reporting, mais un outil CRM de pilotage opérationnel du réseau.
|
||||||
|
Selon moi, l'enjeu n’est donc pas de mesurer :
|
||||||
|
le volume d’usage (connexions, clics…)
|
||||||
|
Mais bien :
|
||||||
|
👉 la capacité du réseau à passer à l’action grâce à Seenaps
|
||||||
|
Autrement dit :
|
||||||
|
Quelle part du réseau est réellement active et pilotée au quotidien ?
|
||||||
|
🌟 2. North Star Metric proposée
|
||||||
|
Taux de points de vente actifs
|
||||||
|
Un point de vente est considéré comme actif s’il a réalisé au moins une action dans Seenaps sur une période donnée.
|
||||||
|
Cette définition a volontairement été choisie pour être :
|
||||||
|
simple
|
||||||
|
mesurable
|
||||||
|
transverse à tous les modules
|
||||||
|
👉 Elle pourra être ajustée dans le temps (ex : fréquence minimale attendue) en fonction des usages observés.
|
||||||
|
Pourquoi ce choix :
|
||||||
|
reflète un usage réel (action ≠ consultation)
|
||||||
|
applicable à tous les cas (formation, com, animation, pilotage…)
|
||||||
|
directement lié à la valeur créée pour le client
|
||||||
|
👉 C’est une métrique qui mesure :
|
||||||
|
la mise en mouvement réelle du réseau
|
||||||
|
🔎 Cas spécifique : module Développement
|
||||||
|
Le module développement ne rentre pas directement dans cette métrique, car il est piloté uniquement par la tête de réseau (et non par les points de vente existants).
|
||||||
|
👉 Ce n’est pas un problème, au contraire :
|
||||||
|
il pourra être suivi via un KPI dédié (ex : taux de transformation candidats → ouvertures, ou autre)
|
||||||
|
il met en évidence le potentiel restant à activer dans le réseau (si module dev uniquement, faible taux de pdv actifs = potentiel business)
|
||||||
|
👉 Et surtout, cela confirme que la valeur principale de Seenaps ne se situe pas uniquement dans le développement, mais bien dans la capacité à piloter et activer un réseau dans la durée.
|
||||||
|
📊 3. Les KPIs qui permettent de piloter la North Star
|
||||||
|
L’idée est de comprendre comment on fait concrètement progresser ce taux.
|
||||||
|
KPI 1 – Taux de sollicitation siège
|
||||||
|
Définition :
|
||||||
|
Part des points de vente ayant reçu au moins une sollicitation (action, formation, communication…)
|
||||||
|
Rôle :
|
||||||
|
👉 Mesure la capacité du siège à activer son réseau
|
||||||
|
Lecture :
|
||||||
|
Si ce KPI est faible → le réseau n’est pas suffisamment piloté
|
||||||
|
KPI 2 – Taux d’activation des PDV
|
||||||
|
Définition :
|
||||||
|
Part des points de vente sollicités qui réalisent une action
|
||||||
|
Rôle :
|
||||||
|
👉 Mesure l’engagement terrain et la pertinence des actions proposées
|
||||||
|
Lecture :
|
||||||
|
Si ce KPI est faible → problème de valeur perçue ou d’appropriation
|
||||||
|
KPI 3 – Délai moyen d’activation
|
||||||
|
Définition :
|
||||||
|
Temps moyen entre une sollicitation et une première action réalisée
|
||||||
|
Rôle :
|
||||||
|
👉 Mesure la fluidité et la facilité d’usage
|
||||||
|
Lecture :
|
||||||
|
Si ce KPI est élevé → friction (outil, compréhension, process)
|
||||||
|
🔁 4. Comment influencer la North Star
|
||||||
|
La North Star est une conséquence directe de 3 leviers :
|
||||||
|
Augmenter la couverture du réseau
|
||||||
|
→ plus de PDV sollicités
|
||||||
|
Améliorer la transformation
|
||||||
|
→ plus de PDV qui passent à l’action
|
||||||
|
Réduire la friction
|
||||||
|
→ accélérer le passage à l’action
|
||||||
|
👉 Concrètement, cela passe par :
|
||||||
|
structurer les sollicitations (formations, actions, contenus…)
|
||||||
|
envoyer des actions claires et actionnables
|
||||||
|
faciliter l’usage côté PDV
|
||||||
|
accompagner les clients dans l’animation de leur réseau
|
||||||
|
🧩 5. Lecture du schéma (pyramide Seenaps) EN PIECE JOINTE
|
||||||
|
Le schéma permet de visualiser simplement la logique :
|
||||||
|
Bas de la pyramide → actions du siège
|
||||||
|
(création de contenus, formations, communications, actions terrain)
|
||||||
|
Milieu → réaction des points de vente
|
||||||
|
(lecture, réalisation, engagement)
|
||||||
|
Haut→ transformation
|
||||||
|
(capacité à faire passer à l’action)
|
||||||
|
Sommet → North Star
|
||||||
|
(% de points de vente actifs)
|
||||||
|
👉 Message clé :
|
||||||
|
la North Star ne se pilote pas directement
|
||||||
|
elle est le résultat de tout ce qui se passe en dessous.
|
||||||
|
🔎 6. Lecture client
|
||||||
|
Ce modèle permet aussi une lecture simple côté client et côté Seenaps :
|
||||||
|
faible taux → réseau peu activé
|
||||||
|
intermédiaire → adoption en cours
|
||||||
|
élevé → Seenaps devient un levier de pilotage
|
||||||
|
👉 Ce qui permet d’ouvrir facilement sur :
|
||||||
|
de l’accompagnement
|
||||||
|
des recommandations
|
||||||
|
de l’upsell
|
||||||
|
🔎 7. Lecture côté collaborateurs Seenaps
|
||||||
|
Ce modèle permet également une lecture opérationnelle en interne, pour identifier rapidement où agir :
|
||||||
|
Taux faible → problème de couverture
|
||||||
|
👉 le réseau n’est pas suffisamment sollicité
|
||||||
|
→ enjeu : mieux structurer l’animation côté client (CSM / accompagnement)
|
||||||
|
Taux intermédiaire avec faible activation
|
||||||
|
👉 les PDV sont sollicités mais passent peu à l’action
|
||||||
|
→ enjeu : améliorer la pertinence des actions et la valeur perçue
|
||||||
|
(produit, contenu, accompagnement)
|
||||||
|
Taux intermédiaire avec bon niveau de sollicitation mais délai long
|
||||||
|
👉 les actions existent mais mettent du temps à être réalisées
|
||||||
|
→ enjeu : réduire la friction (UX, clarté, process)
|
||||||
|
Taux élevé
|
||||||
|
👉 Seenaps est bien intégré dans le fonctionnement du réseau
|
||||||
|
→ enjeu : consolider, industrialiser et identifier des leviers de performance supplémentaires
|
||||||
|
|
||||||
|
## Stéphane
|
||||||
|
À définir mais à mon avis dès que nous avons au moins deux… interactions de type
|
||||||
|
- une visite de renseignee dans les 12 mois
|
||||||
|
- une action de mise à jour dans les 6 mois
|
||||||
|
- une action créée
|
||||||
|
- météo mise à jour
|
||||||
|
- une préparation de visite faite
|
||||||
|
…
|
||||||
|
|
||||||
|
En gros tout ce qui nous permet de lister les interactions managériales de l’animateur.
|
||||||
|
|
||||||
|
|
||||||
255
20-areas/pro/codir/codir-2026-03.md
Normal file
255
20-areas/pro/codir/codir-2026-03.md
Normal file
|
|
@ -0,0 +1,255 @@
|
||||||
|
IA pour Gesteos
|
||||||
|
|
||||||
|
|
||||||
|
Stéphane Trémier
|
||||||
|
|
||||||
|
|
||||||
|
Philippe Aulnette
|
||||||
|
Cas d’usage : IA pour le support client Gesteos
|
||||||
|
|
||||||
|
|
||||||
|
1. Problème actuel (où on en est)
|
||||||
|
Aujourd’hui le support est :
|
||||||
|
|
||||||
|
fortement consommateur de temps humain (N1 + N2)
|
||||||
|
|
||||||
|
peu capitalisé (les réponses sont répétées)
|
||||||
|
|
||||||
|
dépendant des individus (Boris, Sylvie…)
|
||||||
|
|
||||||
|
hétérogène en qualité et en délai
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Conséquence directe :
|
||||||
|
|
||||||
|
coût support élevé
|
||||||
|
|
||||||
|
montée en compétence lente (Tony, futur recruté…)
|
||||||
|
|
||||||
|
pression sur BUILD (Fred)
|
||||||
|
|
||||||
|
expérience client variable
|
||||||
|
|
||||||
|
2. Principe du cas d’usage
|
||||||
|
|
||||||
|
|
||||||
|
👉 Utiliser Claude AI comme moteur de capitalisation et d’assistance au support
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
L’IA est alimentée par :
|
||||||
|
|
||||||
|
tickets historiques (Odoo)
|
||||||
|
|
||||||
|
réponses support existantes
|
||||||
|
|
||||||
|
documentation produit (release notes, guides, aide en ligne)
|
||||||
|
|
||||||
|
bonnes pratiques internes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Objectif :
|
||||||
|
|
||||||
|
transformer chaque ticket traité en connaissance réutilisable
|
||||||
|
|
||||||
|
3. Fonctionnement cible (simple)
|
||||||
|
|
||||||
|
|
||||||
|
Étape 1 — Analyse automatique du ticket
|
||||||
|
|
||||||
|
|
||||||
|
Quand un ticket arrive :
|
||||||
|
|
||||||
|
l’IA identifie :
|
||||||
|
|
||||||
|
le type de problème (ex : facturation, liaison InSitu…)
|
||||||
|
|
||||||
|
la fréquence (problème connu ou nouveau)
|
||||||
|
|
||||||
|
le niveau (N1 vs N2)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Résultat :
|
||||||
|
|
||||||
|
pré-qualification automatique
|
||||||
|
|
||||||
|
gain de temps immédiat
|
||||||
|
|
||||||
|
Étape 2 — Proposition de réponse
|
||||||
|
|
||||||
|
|
||||||
|
L’IA génère :
|
||||||
|
|
||||||
|
un diagnostic
|
||||||
|
|
||||||
|
une checklist de vérification
|
||||||
|
|
||||||
|
une réponse client prête à envoyer
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Exemple :
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
“Avez-vous vérifié X / Y / Z…”
|
||||||
|
|
||||||
|
|
||||||
|
👉 Le support :
|
||||||
|
|
||||||
|
valide / ajuste
|
||||||
|
|
||||||
|
envoie
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Gain :
|
||||||
|
|
||||||
|
plus de rédaction manuelle
|
||||||
|
|
||||||
|
homogénéité des réponses
|
||||||
|
|
||||||
|
Étape 3 — Capitalisation automatique
|
||||||
|
|
||||||
|
|
||||||
|
Chaque ticket traité :
|
||||||
|
|
||||||
|
enrichit une fiche support structurée
|
||||||
|
|
||||||
|
symptôme
|
||||||
|
|
||||||
|
cause
|
||||||
|
|
||||||
|
résolution
|
||||||
|
|
||||||
|
réponse type
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Effet cumulatif :
|
||||||
|
|
||||||
|
amélioration continue
|
||||||
|
|
||||||
|
base de connaissance vivante
|
||||||
|
|
||||||
|
Étape 4 — Assistance proactive
|
||||||
|
|
||||||
|
|
||||||
|
À terme :
|
||||||
|
|
||||||
|
suggestions en temps réel au support
|
||||||
|
|
||||||
|
détection des patterns récurrents
|
||||||
|
|
||||||
|
alerte sur bugs fréquents (remontée BUILD)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Boris passe de “traiter” à “piloter”
|
||||||
|
|
||||||
|
Étape 5 — Self-service client (phase avancée)
|
||||||
|
|
||||||
|
|
||||||
|
Le client peut :
|
||||||
|
|
||||||
|
poser une question directement
|
||||||
|
|
||||||
|
recevoir une réponse IA basée sur la base support
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
👉 Objectif :
|
||||||
|
|
||||||
|
éviter la création du ticket
|
||||||
|
|
||||||
|
4. Cas concret Gesteos
|
||||||
|
|
||||||
|
|
||||||
|
Exemple : problème de liaison InSitu
|
||||||
|
|
||||||
|
|
||||||
|
Aujourd’hui :
|
||||||
|
|
||||||
|
10 tickets similaires
|
||||||
|
|
||||||
|
10 réponses manuelles
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Demain avec IA :
|
||||||
|
|
||||||
|
Claude identifie le pattern
|
||||||
|
|
||||||
|
propose une réponse standard
|
||||||
|
|
||||||
|
guide le client avec une checklist
|
||||||
|
|
||||||
|
résout 60% des cas sans intervention humaine
|
||||||
|
|
||||||
|
5. Impacts attendus (très concrets)
|
||||||
|
|
||||||
|
|
||||||
|
Court terme (1-2 mois)
|
||||||
|
-30% temps de réponse support
|
||||||
|
|
||||||
|
homogénéisation des réponses
|
||||||
|
|
||||||
|
montée en compétence accélérée des juniors
|
||||||
|
|
||||||
|
Moyen terme (3-6 mois)
|
||||||
|
50-60% des tickets assistés ou résolus par IA
|
||||||
|
|
||||||
|
réduction charge N2 (Boris)
|
||||||
|
|
||||||
|
Fred moins sollicité
|
||||||
|
|
||||||
|
Long terme (6-12 mois)
|
||||||
|
self-service partiel client
|
||||||
|
|
||||||
|
support devient scalable
|
||||||
|
|
||||||
|
capacité libérée pour :
|
||||||
|
|
||||||
|
commerce
|
||||||
|
|
||||||
|
onboarding
|
||||||
|
|
||||||
|
delivery
|
||||||
|
|
||||||
|
6. Impacts organisationnels (clé Gesteos)
|
||||||
|
|
||||||
|
|
||||||
|
DELIVERY
|
||||||
|
Boris = pilote du système (plus exécutant)
|
||||||
|
|
||||||
|
N1 augmenté par IA (Tony / futur recruté)
|
||||||
|
|
||||||
|
BUILD
|
||||||
|
moins de bruit support
|
||||||
|
|
||||||
|
meilleure remontée des vrais bugs
|
||||||
|
|
||||||
|
GROWTH
|
||||||
|
temps libéré pour Sylvie
|
||||||
|
|
||||||
|
meilleure expérience client → meilleure conversion
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Logo
|
||||||
|
|
||||||
|
Stéphane Tremier
|
||||||
|
CEO
|
||||||
|
|
||||||
|
RENNES - ANGERS - NANTES - PARIS
|
||||||
|
Mobile : 06 18 45 31 14
|
||||||
|
www.6tm.com
|
||||||
|
Linkedin Youtube
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
69
20-areas/pro/codir/comop-2026.md
Normal file
69
20-areas/pro/codir/comop-2026.md
Normal file
|
|
@ -0,0 +1,69 @@
|
||||||
|
Hello,
|
||||||
|
|
||||||
|
Voici ce que je vois d’un COMOP Factory opérationnel.
|
||||||
|
|
||||||
|
Rôle et mission du COMOP Factory
|
||||||
|
|
||||||
|
Le COMOP est l’instance opérationnelle de pilotage de la Factory.
|
||||||
|
|
||||||
|
Il a pour mission de :
|
||||||
|
- piloter la performance économique, opérationnelle et capacitaire de la Factory,
|
||||||
|
- sécuriser le delivery et la rentabilité,
|
||||||
|
- mettre en œuvre la transformation de la Factory (standardisation, IA, data),
|
||||||
|
- préparer et éclairer les décisions du CODIR, en s’appuyant sur des données factuelles.
|
||||||
|
|
||||||
|
Le COMOP ne se limite pas à coordonner :
|
||||||
|
il arbitre, décide et priorise, dans le cadre fixé par la stratégie 6TM et les OKR.
|
||||||
|
Il rend compte au CODIR.
|
||||||
|
|
||||||
|
Responsabilités du COMOP Factory
|
||||||
|
|
||||||
|
Le COMOP est collectivement responsable de :
|
||||||
|
|
||||||
|
1. Performance économique
|
||||||
|
- TJM société
|
||||||
|
- Marge réelle de la Factory, en intégrant les coûts RH et les frais généraux
|
||||||
|
(tableau de bord de gestion produit par Bruno)
|
||||||
|
- CA
|
||||||
|
- Analyse, décision et accompagnement des projets à risque majeur → Toute décision ayant un impact juridique doit être validée par le Président
|
||||||
|
- Contribution directe à l’atteinte des OKR économiques du groupe
|
||||||
|
|
||||||
|
2. Pilotage des projets et maîtrise des risques
|
||||||
|
- Identification pro-active des projets « casseroles »
|
||||||
|
- Mise en place des plans de redressement
|
||||||
|
- Validation des cadrages initiaux des projets > 200 k€ (à confirmer le montant)
|
||||||
|
- Garantie du respect des standards de la Factory :
|
||||||
|
- qualité
|
||||||
|
- sécurité
|
||||||
|
- pilotage
|
||||||
|
|
||||||
|
3. Pilotage de la capacité et du staffing
|
||||||
|
- Arbitrage de la répartition des charges inter-équipes
|
||||||
|
- Anticipation des besoins capacitaires et compétences
|
||||||
|
|
||||||
|
4. Transformation de la Factory
|
||||||
|
- Pilotage de la standardisation (et donc des OKR et des ateliers CODIR élargi concernés)
|
||||||
|
- Mise en œuvre de l’industrialisation de l’IA dans la production
|
||||||
|
- Cadrage des usages IA non conformes
|
||||||
|
- Application des règles de sécurité SI
|
||||||
|
|
||||||
|
5. Pilotage par les faits
|
||||||
|
- Passage d’un pilotage par les perceptions à un pilotage par les faits
|
||||||
|
- Appui sur Ameno et le contrôle de gestion
|
||||||
|
- Mise en place de tableaux de bord complémentaires si nécessaire
|
||||||
|
|
||||||
|
Participants COMOP Factory
|
||||||
|
OK
|
||||||
|
|
||||||
|
Restitution au CODIR
|
||||||
|
|
||||||
|
Le COMOP restitue au CODIR :
|
||||||
|
- les faits marquants,
|
||||||
|
- les décisions prises,
|
||||||
|
- les points de vigilance,
|
||||||
|
- les arbitrages demandés,
|
||||||
|
- la situation des chantiers portés par le COMOP et des OKR auxquels il contribue.
|
||||||
|
|
||||||
|
À dispo pour en discuter et ajuster si besoin.
|
||||||
|
|
||||||
|
Stéphane
|
||||||
|
|
@ -42,6 +42,16 @@ rythme: hebdo
|
||||||
|
|
||||||
## 📖 Sessions
|
## 📖 Sessions
|
||||||
|
|
||||||
|
### 2026-05-11
|
||||||
|
|
||||||
|
*Préparation Ameno*
|
||||||
|
- Kumulus - ticket
|
||||||
|
- Axone Elastic : passe Yvan, install Vm de prod
|
||||||
|
- Montée de version Leeloo
|
||||||
|
- Julien : processus
|
||||||
|
- Seenaps : base Article /
|
||||||
|
---
|
||||||
|
|
||||||
### 2026-05-04
|
### 2026-05-04
|
||||||
- Axone : Elastic, retour multi-site
|
- Axone : Elastic, retour multi-site
|
||||||
- Seenaps : pt Lionel
|
- Seenaps : pt Lionel
|
||||||
|
|
|
||||||
|
|
@ -39,6 +39,41 @@ rythme: hebdo
|
||||||
|
|
||||||
## 📖 Sessions
|
## 📖 Sessions
|
||||||
|
|
||||||
|
### 2026-05-11
|
||||||
|
|
||||||
|
*Préparation Ameno — semaine du 04 au 10 mai 2026*
|
||||||
|
- **Gesteos - Produit** : 11h gestion de projet ("Bascule mantis / ameno") + 9h direction produit + 1,5h support N2 → **21,5h** sur Gesteos, très majoritairement pilotage/produit
|
||||||
|
- **6TM - Pôle AI** : 2,5h (durée hebdo atteinte) + 2h avant-vente ("AO configurateur SKY agriculture") → signal d'activité commerciale à creuser
|
||||||
|
- **RFE Weekly** : 0,5h
|
||||||
|
- **Orion (Coudray)** : 0,5h gestion de projet
|
||||||
|
- Planification semaine suivante : légère — 2,5h Gesteos + RTT/férié + 0,5h Pôle AI
|
||||||
|
|
||||||
|
*Tickets en cours*
|
||||||
|
- **Gest-Axis-0002** [Bug] — Bug et retours initiaux — *En production*
|
||||||
|
- **Gest-Axis-0003** [Évolution] — Multi-select sur les stats applications — *En production*
|
||||||
|
- **Gest-Axis-0005** [Évolution] — Synchroniser toutes les données Gesteos en une seule fois — *En production*
|
||||||
|
- **Gest-Axis-0006** [Évolution] — KPI Application Insight / télémétrie — *En production*
|
||||||
|
- **Gest-Axis-0007** [Bug] — Nom utilisateur inconnu sur my-tasks — *En production*
|
||||||
|
- **Gest-Prod-0033** [Support] — Accompagnement API Gesteos (Bakertilly Digital) — *En développement* — échéance 01/07
|
||||||
|
|
||||||
|
*Points d'attention*
|
||||||
|
- La bascule Mantis/Ameno semble avoir mobilisé une partie significative de la gestion de projet : s'assurer que c'est derrière, et que le nouveau système est opérationnel.
|
||||||
|
- Gesteos Axis : 5 tickets ouverts en production cette semaine — volume inhabituel pour un démarrage. Risque de dérive en mode "réponse aux tickets" au détriment du fond.
|
||||||
|
- Avant-vente AI (AO SKY agriculture) : signal positif, mais à qualifier — opportunité réelle ou charge subie ?
|
||||||
|
- Planification semaine prochaine très légère : JF + RTT ne justifient pas tout — quel focus est protégé ?
|
||||||
|
- Action ouverte depuis le 27/04 : expliciter 1 objectif prioritaire + 1 livrable attendu de la semaine.
|
||||||
|
|
||||||
|
*Questions à creuser*
|
||||||
|
- La bascule Mantis/Ameno est-elle effective ? Qu'est-ce qui reste à faire ?
|
||||||
|
- Sur Gesteos Axis : ces 5 tickets sont-ils des sujets maîtrisés ou des signaux d'instabilité du produit en prod ?
|
||||||
|
- L'AO SKY agriculture — c'est quoi exactement, à quelle étape, et quelle est la prochaine décision ?
|
||||||
|
- Sur Gest-Prod-0033 (API Bakertilly) : le RAF est à 3,5h pour une échéance au 01/07 — est-ce cadré côté client ?
|
||||||
|
- Quel est l'objectif prioritaire de la semaine à venir, et quel livrable concret en sortira ?
|
||||||
|
|
||||||
|
*Notes de session*
|
||||||
|
|
||||||
|
→ Action :
|
||||||
|
|
||||||
### 2026-04-27
|
### 2026-04-27
|
||||||
|
|
||||||
*Préparation Ameno*
|
*Préparation Ameno*
|
||||||
|
|
|
||||||
61
20-areas/pro/management/1to1/frederic/archives/departMael.md
Normal file
61
20-areas/pro/management/1to1/frederic/archives/departMael.md
Normal file
|
|
@ -0,0 +1,61 @@
|
||||||
|
## retour de Faustine
|
||||||
|
Salut Philippe,
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Suite à ta demande hier soir, je te résume ci-dessous mon échange avec Maël.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Les raisons de son départ :
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Maël m’a confirmé son intention de partir. Il a le sentiment qu’il a fait le tour du poste tel qu’il existe aujourd’hui.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
La partie du métier qui l’anime, faire avancer les projets, analyser etc. est selon lui, devenue trop minoritaire dans son quotidien. Il passe beaucoup de temps à répondre aux sollicitations des clients, à suivre les développeurs sur la saisie, les reportings, etc. Il a l’impression d’être toujours derrière « la culotte » des devs et que sa valeur n’est pas là. Cela ne lui convient plus.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Il pense que le métier de Chef de Projets va évoluer, probablement dans le bon sens avec l’IA. Il se verrait davantage sur un poste comme celui de Romain chez Axone : il se le représente comme un périmètre moins large, permettant d’aller plus en profondeur sur le fonctionnel, tout en restant proche de la technique. Il regrette aujourd’hui de s’en être éloigné.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Par ailleurs, Maël porte depuis longtemps une idée de projet perso et souhaite se laisser un an pour le tester. Il est conscient que ce projet peut ne pas aboutir, mais il regretterait de ne pas avoir tenté. Il n’éprouve plus d’enthousiasme pour le métier de Chef de projets tel qu’il l’exerce actuellement. Il n’exclut toutefois pas de revenir plus tard si de nouveaux postes venaient à se créer.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Concernant son analyse de l’échec d’Hélène :
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Selon Maël, la relation entre le Pôle AI et Gesteos fonctionne aujourd’hui comme une « boucle infinie », alternant phases de tensions très fortes et périodes de légères accalmies… avant que ça clash de nouveau. Hélène est, selon Maël, arrivée au pire moment.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Avec le mode de management très direct de Fred et les retours, positifs comme négatifs, exprimés sans filtre devant l’ensemble de l’équipe, Maël a conscience que cela a pu heurter Hélène, et ce point a d’ailleurs été remonté à Fred par l’équipe. Même si l’intention n’était pas de la viser ou de la mettre en difficulté, dans le contexte actuel, cela a contribué à la crispation d’Hélène et à son sentiment d’attaque permanente.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Maël reste convaincu qu’Hélène, arrivée dans un autre contexte, aurait pu être la bonne personne. En revanche, elle s’est retrouvée au cœur d’une relation qu’il qualifie de « toxique » entre Estelle et Fred, ce qui a clairement pesé sur son intégration.
|
||||||
|
|
||||||
|
|
||||||
|
Il partage également mon constat : Fred est dans le rouge, sous forte pression et si la situation perdure, Maël estime que ce n’est qu’une question de temps avant que Boris ne parte à son tour.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
De mon point de vue, le sujet dépasse largement le cas d’Hélène ou le choix d’un profil en particulier. Tant que les tensions entre Gesteos et le Pôle Ai resteront aussi exacerbées, le contexte ne me paraît pas favorable à l’intégration sereine d’un nouveau collaborateur, quel qu’il soit. Je ne suis donc pas enthousiaste à repartir « tête baissée » dans un nouveau recrutement sans en tirer des leçons.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
J’essayerais d’avoir un point avec @Stéphane pour recueillir son point de vue et ses consignes.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
A dispo pour échanger,
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,156 @@
|
||||||
|
---
|
||||||
|
type: compte-rendu
|
||||||
|
date: 2026-05-09
|
||||||
|
role: Seenaps
|
||||||
|
tags:
|
||||||
|
- seenaps
|
||||||
|
- ia
|
||||||
|
- retro
|
||||||
|
- organisation
|
||||||
|
---
|
||||||
|
|
||||||
|
# CR retro - Usage de l'IA et organisation projets
|
||||||
|
|
||||||
|
## Contexte
|
||||||
|
|
||||||
|
Retro d'equipe autour de deux sujets :
|
||||||
|
|
||||||
|
- usage de l'IA dans les pratiques de developpement ;
|
||||||
|
- organisation projets, rituels et priorites de delivery Seenaps.
|
||||||
|
|
||||||
|
## 1. Usage de l'IA
|
||||||
|
|
||||||
|
### Retours par personne
|
||||||
|
|
||||||
|
#### Maxence
|
||||||
|
|
||||||
|
- Utilisation de Tick6.
|
||||||
|
- Probleme rencontre sur les images en base64.
|
||||||
|
- Usage de `.github/skills` avec demande de reamelioration.
|
||||||
|
- Pas encore d'utilisation de sous-agents.
|
||||||
|
- Piste : knowledge graph pour simplifier la recherche dans le texte.
|
||||||
|
- Modele utilise : Sonnet 4.6.
|
||||||
|
|
||||||
|
#### Christophe
|
||||||
|
|
||||||
|
- Approche davantage basee sur les instructions.
|
||||||
|
- N'utilise pas Tick6 : projet juge trop ancien et moins adapte.
|
||||||
|
- Pas de difference significative constatee entre GitHub Copilot et Copilot selon le contexte actuel.
|
||||||
|
|
||||||
|
#### Valentin
|
||||||
|
|
||||||
|
- Retravail du ticket avec l'IA selon une approche plus gestion de projet : specifications plus detaillees.
|
||||||
|
- Avantage constate sur l'optimisation de Copilot : une seule source de contexte mieux structuree.
|
||||||
|
- Pas d'utilisation de Tick6 : moins pertinent pour les fonctionnalites a construire.
|
||||||
|
- Question ouverte : ou doit vivre ce contenu demain dans le projet ? Dans le ticket ? Dans le repo ? Dans une base de contexte partagee ?
|
||||||
|
|
||||||
|
#### Kevin
|
||||||
|
|
||||||
|
- Utilisation de Tick6.
|
||||||
|
- Completion du ticket avec reformulation en langage humain.
|
||||||
|
- Utilisation de skills pour creer le contexte d'un module dans un sous-dossier local.
|
||||||
|
- Contexte local par feature, avec description du contexte.
|
||||||
|
- Perspective : refactorer progressivement ce contexte en local.
|
||||||
|
- Notion de slice : livrable autonome.
|
||||||
|
- Limite identifiee : l'IA ne voit pas toujours les surcharges.
|
||||||
|
- MCP juge complementaire, exemple cite : Laravel Boost.
|
||||||
|
|
||||||
|
#### Lionel
|
||||||
|
|
||||||
|
- Utilisation d'Opus pour les grosses reviews.
|
||||||
|
- Meilleure prise en compte de l'ensemble des fichiers lors des revues larges.
|
||||||
|
|
||||||
|
## Constats
|
||||||
|
|
||||||
|
- Les usages IA progressent mais restent heterogenes selon les personnes, les outils et les projets.
|
||||||
|
- Le contexte devient le sujet central : instructions, tickets, prompts, documentation, historique et contexte local ne sont pas encore formalises de maniere commune.
|
||||||
|
- Tick6 est utile pour certains cas, mais moins pertinent sur des projets anciens ou sur des fonctionnalites a construire.
|
||||||
|
- Les skills et les instructions semblent etre les leviers les plus actionnables a court terme.
|
||||||
|
- Les MCP sont vus comme un complement utile, pas comme le socle principal.
|
||||||
|
- Les grosses reviews beneficient de modeles plus puissants, notamment pour absorber un grand nombre de fichiers.
|
||||||
|
|
||||||
|
## Points de vigilance
|
||||||
|
|
||||||
|
- Risque de dispersion si chaque personne construit son propre systeme de contexte sans convention commune.
|
||||||
|
- Risque de duplication entre ticket, prompt, documentation projet, instructions repo et historique.
|
||||||
|
- Risque de croire que l'IA compense un manque de specification : les retours montrent plutot que la qualite du ticket reste determinante.
|
||||||
|
- Il manque une regle claire sur ce qui doit etre partage, historise ou garde localement.
|
||||||
|
|
||||||
|
## Actions - V1 IA
|
||||||
|
|
||||||
|
- Formaliser un fichier `instruction.md` ou equivalent.
|
||||||
|
- Formaliser le fonctionnement des agents.
|
||||||
|
- Mettre en place des symlinks vers les instructions quand c'est pertinent.
|
||||||
|
- Formaliser les skills utiles et leur structure.
|
||||||
|
- Documenter les differentes facons de gerer le contexte :
|
||||||
|
- instructions ;
|
||||||
|
- ticket ;
|
||||||
|
- prompt ;
|
||||||
|
- contexte complementaire ;
|
||||||
|
- documentation projet ;
|
||||||
|
- historique.
|
||||||
|
- Definir les docs comme source de verite consolidee.
|
||||||
|
- Clarifier les regles de partage :
|
||||||
|
- ce qui doit etre partage dans l'equipe ;
|
||||||
|
- ce qui peut rester local ;
|
||||||
|
- ce qui doit etre historise ;
|
||||||
|
- la cible prochaine.
|
||||||
|
|
||||||
|
## Rituels IA
|
||||||
|
|
||||||
|
- Mettre en place un point de synchronisation toutes les deux semaines.
|
||||||
|
- Prevoir un deuxieme abonnement Claude.
|
||||||
|
|
||||||
|
## 2. Organisation projets
|
||||||
|
|
||||||
|
### Valeur et delivery
|
||||||
|
|
||||||
|
- Recentrer la discussion sur la valeur livree.
|
||||||
|
- Exemple cite par Kevin : assistance.
|
||||||
|
- Indicateur a suivre : a quelle vitesse delivre-t-on ?
|
||||||
|
- Exemple de mesure possible : nombre de tickets en tests.
|
||||||
|
- Monter en hauteur dans le pilotage, au-dela du suivi operationnel ticket par ticket.
|
||||||
|
|
||||||
|
### Demos
|
||||||
|
|
||||||
|
- Cible : demonstration de 30 minutes maximum.
|
||||||
|
- Preparation necessaire en amont.
|
||||||
|
- Jeux de tests prets avant la demo.
|
||||||
|
- Cible : une seule personne responsable de la demo.
|
||||||
|
|
||||||
|
### Experimentations
|
||||||
|
|
||||||
|
- Manop.
|
||||||
|
- Support : optimisation de la gestion des tickets.
|
||||||
|
|
||||||
|
## Priorites / cailloux
|
||||||
|
|
||||||
|
- MonoBase.
|
||||||
|
- CI et migrations.
|
||||||
|
- Tests.
|
||||||
|
- Suppressions Azure.
|
||||||
|
- Permissions / habilitations.
|
||||||
|
- UX / UI.
|
||||||
|
- En parallele : travail sur les skills.
|
||||||
|
|
||||||
|
## Gitflow
|
||||||
|
|
||||||
|
- Validation du gitflow.
|
||||||
|
- ADR a mettre a jour par Christophe.
|
||||||
|
|
||||||
|
## Decisions
|
||||||
|
|
||||||
|
- Mettre en place un rituel de synchronisation IA toutes les deux semaines.
|
||||||
|
- Structurer une V1 des instructions, agents et skills.
|
||||||
|
- Traiter la documentation comme source de verite consolidee.
|
||||||
|
- Limiter les demos a 30 minutes avec un responsable unique et des jeux de tests prets.
|
||||||
|
- Mettre a jour l'ADR gitflow.
|
||||||
|
|
||||||
|
## Questions ouvertes
|
||||||
|
|
||||||
|
- Ou doit vivre le contexte enrichi par l'IA : ticket, repo, documentation, ou combinaison explicite des trois ?
|
||||||
|
- Quelle frontiere entre contexte local utile a un developpeur et contexte partage obligatoire ?
|
||||||
|
- Quel format standard pour une slice livrable ?
|
||||||
|
- Quels criteres pour choisir entre Copilot, Claude, Opus, Tick6 et MCP selon le type de tache ?
|
||||||
|
- Quel indicateur de delivery retenir en premier : tickets en tests, lead time, cycle time, ou autre ?
|
||||||
|
|
||||||
BIN
20-areas/pro/seenaps/Memo-Repositionnement-Seenaps.pptx
Normal file
BIN
20-areas/pro/seenaps/Memo-Repositionnement-Seenaps.pptx
Normal file
Binary file not shown.
BIN
20-areas/pro/seenaps/OKR-Organisation-Seenaps-2026.pptx
Normal file
BIN
20-areas/pro/seenaps/OKR-Organisation-Seenaps-2026.pptx
Normal file
Binary file not shown.
15
20-areas/pro/seenaps/budget/budget-seenaps.md
Normal file
15
20-areas/pro/seenaps/budget/budget-seenaps.md
Normal file
|
|
@ -0,0 +1,15 @@
|
||||||
|
| Société | Nom | Poste | Contrat | Taux |
|
||||||
|
|---|---|---|---|---:|
|
||||||
|
| 6tm | Michel FAILLIE | Responsable de l'agence d'Angers | CDI | 30 |
|
||||||
|
| 6tm | Sandrine JUBLAN | SDA | CDI | 100 |
|
||||||
|
| 6tm | Stéphane TREMIER | Président | Dirigeant | 20 |
|
||||||
|
| 6tm | Valentin RENARD | Développeur | CDI | 60 |
|
||||||
|
| 6tm | Yvan LOICHON | Lead Front-Intégrateur | CDI | 20 |
|
||||||
|
| hegyd | Aurélie BLOT | Customer Succes Manager | CDI | 100 |
|
||||||
|
| hegyd | Kévin HAMON | Développeur | CDI | 100 |
|
||||||
|
| hegyd | Maxence MARTIN | Contrat d'apprentissage | Contrat de professionnalisation en CDD | 50 |
|
||||||
|
| hegyd | Quentin BONTEMPS | Responsable d'équipe | CDI | 20 |
|
||||||
|
| 6tm | Philippe AULNETTE | Prestataire | PRESTATAIRE | 40 |
|
||||||
|
| hegyd | Lionel GUERIN | Développeur | CDI | 100 |
|
||||||
|
| hegyd | Bastien GRUNDREICH | Business Développement Manager Seenaps | CDI | 100 |
|
||||||
|
| Hegyd | Jérémie QUINSON | Prestataire | PRESTATAIRE | 100 |
|
||||||
5
20-areas/pro/seenaps/concurrent/cerca/cerca-actualite.md
Normal file
5
20-areas/pro/seenaps/concurrent/cerca/cerca-actualite.md
Normal file
|
|
@ -0,0 +1,5 @@
|
||||||
|
## 2025-07
|
||||||
|
BFM : Olivier Pires Bajalune
|
||||||
|
400 clients - 40 000 points de vente
|
||||||
|
25 personnes
|
||||||
|
https://www.bfmtv.com/economie/replay-emissions/hashtag-decryptage/cerca-une-solution-tout-en-un-au-service-des-entreprises_AB-202507290018.html
|
||||||
|
|
@ -0,0 +1,155 @@
|
||||||
|
# Cerca (Groupe Axone) — Analyse comptes 2024 + valorisation déc. 2025
|
||||||
|
|
||||||
|
## Identité
|
||||||
|
|
||||||
|
- **SAS Groupe Axone** (RCS Troyes 788 912 939) — éditeur de **Cerca** (ex-Franchise On Cloud, rebranding mars 2024)
|
||||||
|
- Siège : Macey (10300) • Capital : 22 766 €
|
||||||
|
- Positionnement : SaaS pure player pour réseaux de franchise / commerce associé — **400+ enseignes clientes**
|
||||||
|
|
||||||
|
## Actionnariat Groupe Axone
|
||||||
|
|
||||||
|
### Avant apport (jusqu'au 16/12/2025)
|
||||||
|
|
||||||
|
| Associé | Actions | % | Valeur (131,78 €/action) |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Olivier Bajaluna | 14 569 | 63,99 % | 1 920 K€ |
|
||||||
|
| Grégory Clément | 3 139 | 13,79 % | 414 K€ |
|
||||||
|
| Mathieu Bajaluna | 2 277 | 10,00 % | 300 K€ |
|
||||||
|
| Elodie Bajaluna | 2 277 | 10,00 % | 300 K€ |
|
||||||
|
| Proximo SAS | 276 | 1,21 % | 36 K€ |
|
||||||
|
| Louis Chevalier | 227 | 1,00 % | 30 K€ |
|
||||||
|
| Monique Bajaluna | 1 | 0,004 % | 132 € |
|
||||||
|
| **Total** | **22 766** | **100 %** | **3 000 K€** |
|
||||||
|
|
||||||
|
### Après apport (à compter du 17/12/2025)
|
||||||
|
|
||||||
|
Olivier Bajaluna a apporté 9 800 de ses actions à la nouvelle **SARL Holding Bajaluna** (capital 1 291 444 €, dont il est associé unique).
|
||||||
|
|
||||||
|
| Associé | Actions | % |
|
||||||
|
|---|---:|---:|
|
||||||
|
| **Holding Bajaluna** (Olivier B.) | 9 800 | **43,05 %** |
|
||||||
|
| Olivier Bajaluna (direct) | 4 769 | 20,95 % |
|
||||||
|
| Grégory Clément | 3 139 | 13,79 % |
|
||||||
|
| Mathieu Bajaluna | 2 277 | 10,00 % |
|
||||||
|
| Elodie Bajaluna | 2 277 | 10,00 % |
|
||||||
|
| Proximo SAS | 276 | 1,21 % |
|
||||||
|
| Louis Chevalier | 227 | 1,00 % |
|
||||||
|
| Monique Bajaluna | 1 | 0,004 % |
|
||||||
|
|
||||||
|
**Contrôle famille Bajaluna (direct + holding) : 84,00 %**
|
||||||
|
|
||||||
|
### Lecture
|
||||||
|
|
||||||
|
- Opération classique de **structuration patrimoniale** : Olivier Bajaluna interpose une holding entre lui et l'éditeur, sans modifier le contrôle ni la gouvernance opérationnelle. Pas une opération de cession.
|
||||||
|
- Bénéfices recherchés : régime mère-fille (remontée de dividendes en quasi-franchise IS), apport-cession différé, transmission familiale future facilitée
|
||||||
|
- Olivier Bajaluna conserve le contrôle (43 % via holding + 21 % direct = **64 % consolidé**, identique à avant)
|
||||||
|
- Mathieu et Elodie Bajaluna (10 % chacun) = vraisemblablement enfants — **transmission générationnelle déjà amorcée**
|
||||||
|
- Grégory Clément (13,79 %) = associé opérationnel historique non-Bajaluna (probable cofondateur ou cadre clé)
|
||||||
|
- Proximo SAS (1,21 %) = participation minoritaire d'une société tierce, à creuser
|
||||||
|
|
||||||
|
## Valorisation officielle (décembre 2025)
|
||||||
|
|
||||||
|
Validée par le **Cabinet Rioux** (commissaire aux apports, Saint-Malo) le 17/12/2025 :
|
||||||
|
|
||||||
|
- **Valeur unitaire : 131,78 € / action**
|
||||||
|
- **Valorisation 100 % du capital : 3 000 103 €** (~3 M€)
|
||||||
|
- Multiple sur capitaux propres 2024 : **4,6x** (650 K€ → 3 000 K€)
|
||||||
|
- **PER (multiple sur résultat net 2024) : 10,9x**
|
||||||
|
|
||||||
|
À nuancer : valorisation d'apport entre parties liées, validée comme « non surévaluée » — donc un **plancher prudent**, pas un prix de marché. Une vraie cession à un industriel ou un fonds tirerait probablement vers 2-3x ARR ou 12-18x EBITDA, soit **3-6 M€** selon CA réel.
|
||||||
|
|
||||||
|
## Chiffres clés (bilan 2024, CR confidentiel)
|
||||||
|
|
||||||
|
| Indicateur | 2024 | 2023 | Var. |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Total bilan | 1 485 K€ | 1 246 K€ | +19 % |
|
||||||
|
| Capitaux propres | **650 K€** | 374 K€ | **+74 %** |
|
||||||
|
| Résultat net | **276 601 €** | 245 674 € | +13 % |
|
||||||
|
| Trésorerie nette réelle | +167 K€ | +117 K€ | +43 % |
|
||||||
|
| Dette financière nette | **-27 K€** | +106 K€ | désendettement |
|
||||||
|
|
||||||
|
CA et effectifs **non publiés** (confidentialité partielle → CA < 12 M€). Effectif estimé 10-20 ETP.
|
||||||
|
|
||||||
|
## Estimation du CA 2024 (triangulation)
|
||||||
|
|
||||||
|
Le compte de résultat n'étant pas publié, on triangule à partir de plusieurs indices indirects.
|
||||||
|
|
||||||
|
### Indices disponibles
|
||||||
|
|
||||||
|
| Indice | Donnée | Lecture |
|
||||||
|
|---|---|---|
|
||||||
|
| Dettes fiscales et sociales | 474 K€ | Activité significative (PME, pas micro) ; IS estimé ~92 K€ |
|
||||||
|
| Activation R&D | +106 K€ en 2024 | Masse salariale R&D ~210 K€ → 3-4 devs |
|
||||||
|
| ROE | 42,5 % | Très élevé, typique éditeur rentable |
|
||||||
|
| Valorisation Rioux | 3 M€ | Plancher prudent |
|
||||||
|
| Effectif estimé | 10-20 ETP | Cohérent indices internes |
|
||||||
|
|
||||||
|
### Méthode 1 — par marge nette typique SaaS PME (8-15 %)
|
||||||
|
|
||||||
|
| Marge nette hypothèse | CA implicite |
|
||||||
|
|---:|---:|
|
||||||
|
| 8 % | 3,5 M€ |
|
||||||
|
| 10 % | 2,8 M€ |
|
||||||
|
| **12 %** | **2,3 M€** |
|
||||||
|
| 15 % | 1,8 M€ |
|
||||||
|
| 20 % | 1,4 M€ |
|
||||||
|
|
||||||
|
### Méthode 2 — par ARPU sur 400 enseignes
|
||||||
|
|
||||||
|
| ARPU mensuel hypothèse | CA implicite |
|
||||||
|
|---:|---:|
|
||||||
|
| 300 €/mois | 1,4 M€ |
|
||||||
|
| **500 €/mois** | **2,4 M€** |
|
||||||
|
| 700 €/mois | 3,4 M€ |
|
||||||
|
|
||||||
|
### Méthode 3 — par multiple EV/Sales (1,5-2x typique éditeur PME)
|
||||||
|
|
||||||
|
Valorisation 3 M€ → CA implicite **1,5 à 2 M€** (plancher).
|
||||||
|
|
||||||
|
### Synthèse
|
||||||
|
|
||||||
|
```
|
||||||
|
Marge nette 10-15 % → 1,8 à 2,8 M€
|
||||||
|
ARPU 400-600 €/mois → 1,9 à 2,9 M€
|
||||||
|
Multiple revenus 1,5x → 2,0 M€
|
||||||
|
```
|
||||||
|
|
||||||
|
→ **Fourchette CA 2024 estimée : 1,8 à 2,5 M€**
|
||||||
|
→ **Point médian le plus probable : ~2,2 M€**
|
||||||
|
|
||||||
|
**Marge d'incertitude : ±30 %**. Pour confirmation exacte : Pappers Premium, Diane (Bureau Van Dijk) ou Société.com Premium.
|
||||||
|
|
||||||
|
## Lecture financière
|
||||||
|
|
||||||
|
- **Très saine** : autonomie financière 44 %, gearing négatif, autofinancement intégral (0 dividende, tout en réserves)
|
||||||
|
- **BFR négatif (-96 K€)** : modèle SaaS facturé d'avance classique
|
||||||
|
- **R&D capitalisée 1 M€ brut** (607 K€ net) — activation 2024 (+106 K€) < dotation (179 K€) → **stock R&D net décroît**, signal de consolidation produit plutôt que rupture
|
||||||
|
- **Point d'attention : créances clients ×4** (81 → 331 K€). Pas de provision → pas perçu comme à risque, mais à surveiller (allongement délais ? mix grands comptes ?)
|
||||||
|
|
||||||
|
## Implications pour Seenaps / 6TM
|
||||||
|
|
||||||
|
| | Cerca | Seenaps (6TM) |
|
||||||
|
|---|---|---|
|
||||||
|
| Modèle | Éditeur pur | Éditeur + ESN |
|
||||||
|
| Taille | 10-20 ETP | ~100 (dont 50 devs) |
|
||||||
|
| CA estimé | ~2,2 M€ | n/a |
|
||||||
|
| Marge structurelle | Élevée (SaaS standardisé) | Diluée par services |
|
||||||
|
| Capacité sur-mesure | Faible | **Forte** |
|
||||||
|
| Valorisation officielle | ~3 M€ (déc. 2025) | n/a |
|
||||||
|
| Contrôle | 84 % famille (verrouillé) | n/a |
|
||||||
|
|
||||||
|
**Lecture stratégique** :
|
||||||
|
|
||||||
|
1. Concurrent **petit, durable, verrouillé** — autofinancé, contrôle familial 84 %, holding patrimoniale en place → **aucune fenêtre de M&A à court terme**, ils ne sont pas vendeurs
|
||||||
|
2. CA estimé ~2,2 M€ pour 400+ enseignes → **ARPU faible (~450 €/mois/enseigne)** → produit positionné sur le segment franchise milieu de gamme, peu de grands comptes
|
||||||
|
3. **Talon d'Achille** : produit très standardisé (ratio 400 clients / ~15 ETP) → faible capacité à délivrer du sur-mesure → **angle d'attaque Seenaps** sur les enseignes exigeantes
|
||||||
|
4. **Fenêtre IA** : ralentissement R&D activée + comm produit ("premiers à intégrer l'IA") plutôt cosmétique → opportunité d'accélération sur ton OKR Seenaps IA 2026
|
||||||
|
5. Cerca est certifié **ISO 27001** — point de vigilance compétitif côté Seenaps DataShield / sécurité
|
||||||
|
6. La transmission générationnelle amorcée (Mathieu et Elodie à 10 % chacun) peut **déstabiliser le pilotage** dans 5-10 ans si les enfants ne reprennent pas l'opérationnel — fenêtre M&A possible à moyen terme
|
||||||
|
|
||||||
|
## À compléter
|
||||||
|
|
||||||
|
- Compte de résultat exact (Pappers Premium / Diane) → CA, masse salariale, marge nette pour valider l'estimation
|
||||||
|
- Liste enseignes clientes pour cartographier recouvrement vs Seenaps
|
||||||
|
- Identifier Proximo SAS (associé à 1,21 %) et Louis Chevalier (1,00 %)
|
||||||
|
- Comparaison fonctionnelle module à module
|
||||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
33
20-areas/pro/seenaps/marketing/marketing-seenaps.md
Normal file
33
20-areas/pro/seenaps/marketing/marketing-seenaps.md
Normal file
|
|
@ -0,0 +1,33 @@
|
||||||
|
|
||||||
|
## postionnement et action Gaetan
|
||||||
|
|
||||||
|
En rebond de l’action commerciale test « frontale cerca » et conjointement aux réflexions que j’ai eu sur Seenaps ces derniers jours (étude marché, concurrence, positionnement…) je me suis reposé sur les opportunités/risques.
|
||||||
|
|
||||||
|
Je partage la lecture du "frontale Cerca » sur le tarif qui doit nous permettre de revenir dans le match sur les leads que nous perdons habituellement.
|
||||||
|
|
||||||
|
Je partage néanmoins quelques points de vigilance, suggestions et proposition de plan d’actions en parallèle. Tout ça ce challenge aussi 😊
|
||||||
|
|
||||||
|
3 points de vigilance de l’attaque Cerca sur les prix.
|
||||||
|
|
||||||
|
1 - Gagner des parts de marché oui, gagner le bras de fer avec Cerca même à moyen long terme me semble plus compliqué. Cerca pèse environ 10x notre CA SaaS (ciblage mid market voire grosses franchises). Ils ont une machine commerciale & marketing structurée bien huilées, ils ont pignon sur rue et une marque qui semble toujours en accélération.
|
||||||
|
|
||||||
|
2 - Devenir leader par le prix sur leur terrain de force risque d’être compliqué. Ils peuvent aussi baisser leurs prix en réponse. Je pense qu’ils ont la structure, les reins et la combativité pour aller nous chercher sur ce terrain. A voir si on veut jouer à ce jeu dans le temps ? avec les complications que cela peut apporter et finalement nous dérouter de notre vrai valeur.
|
||||||
|
|
||||||
|
3 - Si nos clients actuels et précédents prospects apprennent que l'on a accordé des conditions super avantageuses. Risque qu'ils reviennent au renouvellement ou avant avec cet argument avec le risque de nous pourrir. Prévoir notre argumentaire si cela arrive (la 1ere suggestion ci-dessous est une possibilité)
|
||||||
|
|
||||||
|
2 Suggestions :
|
||||||
|
|
||||||
|
1 - Avoir un garde fou pour vendre l'offre « agressive" comme une gamme distincte avec un scope précis et non comme une remise sur Seenaps Platform. Cela protège notre crédibilité « premium" auprès des clients existants : ils peuvent identifier que c'est un produit différent, pas le même produit moins cher.
|
||||||
|
|
||||||
|
2 - Quel timing on se donne sur le test ? Et quels KPIs ? On peut se donner 6 mois par exemple et mesurer : nombre de leads gagné, taux de conversion, timing cycle de vente, nombre d’opportunités upsell et crossell (seenaps services).
|
||||||
|
|
||||||
|
|
||||||
|
1 Plan complémentaire.
|
||||||
|
|
||||||
|
Investir en parallèle sur les segments où nous pouvons devenir leader 😉
|
||||||
|
|
||||||
|
Comme je le mentionne dans l’étude, il existe un axe que Cerca ne semble pas couvrir, ni Cléonet et où Yoobic n’est pas pertinent => le commerce associé (les coopératives) et le multi-typologies qui basculent leur structure du commerce intégré vers l’organisé. On sait faire et on a de la valeur (cf Maisons du Monde).
|
||||||
|
|
||||||
|
Je propose de construire en parallèle un plan d'actions marketing et commercial sur ces segments : ciblage précis, contenus, relancer les partenariats institutionnels (FCA notamment), événements verticalisés.
|
||||||
|
|
||||||
|
A dispo pour échanger.
|
||||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
171
20-areas/pro/seenaps/userResearch/quadro.md
Normal file
171
20-areas/pro/seenaps/userResearch/quadro.md
Normal file
|
|
@ -0,0 +1,171 @@
|
||||||
|
---
|
||||||
|
type: user-research
|
||||||
|
client: Quadro
|
||||||
|
role: seenaps
|
||||||
|
theme:
|
||||||
|
- animation-reseau
|
||||||
|
- pilotage
|
||||||
|
- ia
|
||||||
|
- gesteos
|
||||||
|
source:
|
||||||
|
date:
|
||||||
|
---
|
||||||
|
|
||||||
|
# Quadro - retour user research Seenaps
|
||||||
|
|
||||||
|
## Synthèse
|
||||||
|
|
||||||
|
Quadro confirme que le problème principal n'est pas l'absence d'outils, mais la fragmentation, la perte de temps et la difficulté à transformer la donnée en action.
|
||||||
|
|
||||||
|
Ils disposent déjà de Teams, dossiers documentaires, reporting, boutique, formation, etc. Leur intérêt pour Seenaps n'est donc pas "un outil de plus", mais un facilitateur centralisateur qui augmente la valeur des données existantes et fluidifie la coopération.
|
||||||
|
|
||||||
|
Ce retour est fortement aligné avec le repositionnement Seenaps : un outil de pilotage et d'animation de réseau, pas un simple outil de communication.
|
||||||
|
|
||||||
|
## Signal principal
|
||||||
|
|
||||||
|
Les usages à forte valeur identifiés sont :
|
||||||
|
|
||||||
|
- préparation des visites ;
|
||||||
|
- suivi des plans d'action ;
|
||||||
|
- capacité managériale à voir en temps réel ce que font les animateurs.
|
||||||
|
|
||||||
|
C'est le coeur de la promesse Seenaps autour de l'animation, du CRM réseau et des recommandations automatiques.
|
||||||
|
|
||||||
|
## Pain point principal
|
||||||
|
|
||||||
|
Le besoin le plus fort n'est pas la communication descendante. C'est le pilotage opérationnel :
|
||||||
|
|
||||||
|
- préparer plus vite les rendez-vous ;
|
||||||
|
- structurer le reporting ;
|
||||||
|
- suivre réellement l'exécution des plans d'action ;
|
||||||
|
- relancer sans épuiser les équipes ;
|
||||||
|
- rendre visibles les priorités par magasin et par niveau d'alerte.
|
||||||
|
|
||||||
|
Quadro exprime que la valeur est moins dans le constat que dans le passage :
|
||||||
|
|
||||||
|
1. du constat au plan d'action ;
|
||||||
|
2. du plan d'action au suivi ;
|
||||||
|
3. du suivi à l'exécution réelle.
|
||||||
|
|
||||||
|
Conclusion produit : le module clé n'est pas le reporting, mais la boucle d'exécution terrain.
|
||||||
|
|
||||||
|
## Seenaps + Gesteos
|
||||||
|
|
||||||
|
Slav et Laurent pointent un risque majeur : la cohérence des chiffres et la duplication d'information entre Seenaps et Gesteos.
|
||||||
|
|
||||||
|
Ils ne refusent pas la complémentarité. Au contraire, ils la jugent intéressante. Mais ils posent une condition : une vérité de donnée claire.
|
||||||
|
|
||||||
|
Sans cela :
|
||||||
|
|
||||||
|
- l'utilisateur magasin sera perdu ;
|
||||||
|
- la crédibilité du système baissera ;
|
||||||
|
- les équipes risquent de contourner l'outil.
|
||||||
|
|
||||||
|
Positionnement cible :
|
||||||
|
|
||||||
|
- Seenaps devient le cockpit de pilotage réseau ;
|
||||||
|
- Gesteos reste le système opérationnel magasin ;
|
||||||
|
- des règles d'arbitrage explicites définissent où vit la donnée et quelle source fait foi.
|
||||||
|
|
||||||
|
## Manuel dynamique et capitalisation métier
|
||||||
|
|
||||||
|
Le passage le plus riche de l'entretien concerne le manuel dynamique et la capitalisation du savoir-faire métier des animateurs.
|
||||||
|
|
||||||
|
Le client formule presque le futur produit :
|
||||||
|
|
||||||
|
- transformer les reportings terrain en base de savoir vivant ;
|
||||||
|
- identifier automatiquement les similitudes dans les plans d'action ;
|
||||||
|
- faire émerger des pratiques recommandées ;
|
||||||
|
- soumettre ces pratiques à validation de la tête de réseau ;
|
||||||
|
- réinjecter les apprentissages dans le manuel dynamique ;
|
||||||
|
- accélérer l'intégration des nouveaux animateurs.
|
||||||
|
|
||||||
|
Ce n'est pas une promesse d'IA magique. C'est une promesse de digitalisation du savoir métier, de formation embarquée et d'amélioration continue du réseau.
|
||||||
|
|
||||||
|
C'est une différenciation verticale plus défendable qu'un simple résumé automatique. Elle colle aussi aux orientations autour des agents spécialisés, des copilotes métiers et de l'industrialisation de l'IA appliquée.
|
||||||
|
|
||||||
|
## Perception de l'IA
|
||||||
|
|
||||||
|
La position de Quadro est nuancée :
|
||||||
|
|
||||||
|
- l'IA n'est pas rejetée ;
|
||||||
|
- elle n'est pas vue comme un gadget ;
|
||||||
|
- elle doit rester un facilitateur et ne pas remplacer le jugement métier ;
|
||||||
|
- le risque est de produire une synthèse trop courte qui fait rater l'important ;
|
||||||
|
- la vraie valeur est dans le coaching, la vigilance et l'aide à prendre du recul.
|
||||||
|
|
||||||
|
Point de discours important : ne pas vendre l'automatisation du métier d'animateur, mais l'augmentation de la qualité du métier d'animateur et de directeur réseau.
|
||||||
|
|
||||||
|
## Portage AGEM
|
||||||
|
|
||||||
|
Le sujet est porté par la maison mère AGEM. C'est important pour le discours marché : l'enjeu dépasse un besoin local Quadro et peut nourrir une proposition de valeur groupe.
|
||||||
|
|
||||||
|
## Game changer pour Quadro
|
||||||
|
|
||||||
|
Le game changer n'est pas un gain de temps abstrait. Il est très concret : permettre à une équipe terrain de couvrir plus de points de vente sans dégrader la qualité d'animation.
|
||||||
|
|
||||||
|
Ils parlent clairement de :
|
||||||
|
|
||||||
|
- repousser le seuil de recrutement d'un animateur supplémentaire ;
|
||||||
|
- augmenter le nombre de magasins gérés par tête ;
|
||||||
|
- améliorer le contrôle et l'exécution.
|
||||||
|
|
||||||
|
Formulation de proposition de valeur :
|
||||||
|
|
||||||
|
> Seenaps est un levier de productivité managériale mesurable et de montée en performance réseau.
|
||||||
|
|
||||||
|
Angle commercial possible :
|
||||||
|
|
||||||
|
> Vous permettre de tenir 22 à 30 points de vente par animateur avec un meilleur contrôle et une meilleure exécution.
|
||||||
|
|
||||||
|
## Implications roadmap
|
||||||
|
|
||||||
|
### Plan d'action augmenté
|
||||||
|
|
||||||
|
- Suivi des actions.
|
||||||
|
- Relances intelligentes.
|
||||||
|
- Visibilité partagée.
|
||||||
|
- Gestion des retards.
|
||||||
|
- Échéances.
|
||||||
|
- Priorisation.
|
||||||
|
|
||||||
|
### Cockpit animateur / directeur réseau
|
||||||
|
|
||||||
|
- Préparation de visite.
|
||||||
|
- Synthèse des signaux faibles.
|
||||||
|
- Arbitrage des urgences.
|
||||||
|
- Vue portefeuille magasins.
|
||||||
|
|
||||||
|
### Base de savoir dynamique
|
||||||
|
|
||||||
|
- Extraction de patterns depuis les reportings.
|
||||||
|
- Suggestions de bonnes pratiques.
|
||||||
|
- Validation par la tête de réseau.
|
||||||
|
|
||||||
|
### Gouvernance de la donnée Seenaps / Gesteos
|
||||||
|
|
||||||
|
- Définition du référentiel de chiffres.
|
||||||
|
- Mapping des sources.
|
||||||
|
- Règles d'usage.
|
||||||
|
- Définition de la source faisant foi.
|
||||||
|
|
||||||
|
### IA coach métier
|
||||||
|
|
||||||
|
- Check de complétude.
|
||||||
|
- Suggestions de questions.
|
||||||
|
- Proposition de next best action.
|
||||||
|
- Aide à la prise de recul.
|
||||||
|
|
||||||
|
## Points à challenger
|
||||||
|
|
||||||
|
- Si Seenaps devient le cockpit, quelles données doivent impérativement rester dans Gesteos ?
|
||||||
|
- Qui est responsable de la qualité de la donnée entre magasin, animateur, tête de réseau et système opérationnel ?
|
||||||
|
- La promesse "22 à 30 PDV par animateur" est forte : elle doit être validée par un benchmark ou un pilote mesurable.
|
||||||
|
- Attention à ne pas réduire l'IA à de la synthèse : Quadro attend surtout de l'aide à l'exécution, au coaching et à la vigilance.
|
||||||
|
- Le manuel dynamique ne doit pas devenir une base documentaire passive. Sa valeur dépend de la boucle terrain -> validation -> recommandation -> réutilisation.
|
||||||
|
|
||||||
|
## Prochaine action
|
||||||
|
|
||||||
|
- Définir un scénario pilote centré sur la boucle d'exécution terrain : préparation de visite, plan d'action, relance et suivi.
|
||||||
|
- Clarifier la gouvernance de donnée Seenaps / Gesteos sur 3 à 5 indicateurs critiques.
|
||||||
|
- Tester la proposition de valeur "points de vente pilotés par animateur" avec Quadro.
|
||||||
195
40-playbooks/veille-hebdo-tech-ia.md
Normal file
195
40-playbooks/veille-hebdo-tech-ia.md
Normal file
|
|
@ -0,0 +1,195 @@
|
||||||
|
# Veille Hebdomadaire Tech & IA (Playbook 1/2)
|
||||||
|
|
||||||
|
## Objectif
|
||||||
|
|
||||||
|
Produire chaque semaine une veille Tech & IA synthétique, sourcée et actionnable.
|
||||||
|
**Cadence :** Dimanche 19h (20 min)
|
||||||
|
**Audience :** Équipes tech, Product, Devs
|
||||||
|
**Focus :** Tools, frameworks, Platform AI, patterns agents (accélération livraison)
|
||||||
|
|
||||||
|
Cette veille doit m’aider à suivre les évolutions importantes en :
|
||||||
|
- IA générative ;
|
||||||
|
- agents IA ;
|
||||||
|
- développement logiciel assisté par IA ;
|
||||||
|
- outils développeurs ;
|
||||||
|
- architecture logicielle ;
|
||||||
|
- sécurité, RGPD et gouvernance IA ;
|
||||||
|
- cloud, DevOps et observabilité ;
|
||||||
|
- product management augmenté par IA.
|
||||||
|
|
||||||
|
Elle doit être utile pour un Product Owner / responsable projet IT dans une entreprise tech d’environ 100 personnes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Période analysée
|
||||||
|
|
||||||
|
Analyser les publications, annonces et nouveautés des **7 derniers jours**.
|
||||||
|
|
||||||
|
Si une information plus ancienne est utile pour comprendre un sujet récent, l’indiquer clairement.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sources à privilégier
|
||||||
|
|
||||||
|
Prioriser les sources primaires et fiables :
|
||||||
|
|
||||||
|
### IA & agents
|
||||||
|
|
||||||
|
- OpenAI News
|
||||||
|
- OpenAI Developers
|
||||||
|
- OpenAI Codex Changelog
|
||||||
|
- Anthropic News
|
||||||
|
- Claude Code Changelog
|
||||||
|
- Google DeepMind Blog
|
||||||
|
- Google AI Blog
|
||||||
|
- Microsoft AI Blog
|
||||||
|
- Mistral AI News
|
||||||
|
- Meta AI Blog
|
||||||
|
|
||||||
|
### Recherche & modèles
|
||||||
|
|
||||||
|
- arXiv cs.CL
|
||||||
|
- arXiv cs.AI
|
||||||
|
- Papers with Code
|
||||||
|
- Hugging Face Papers
|
||||||
|
- Hugging Face Trending Papers
|
||||||
|
- LMSYS / Chatbot Arena
|
||||||
|
- Artificial Analysis
|
||||||
|
- Stanford AI Index
|
||||||
|
- Epoch AI
|
||||||
|
|
||||||
|
### Open source IA
|
||||||
|
|
||||||
|
- Hugging Face Blog
|
||||||
|
- LangChain Blog
|
||||||
|
- LlamaIndex Blog
|
||||||
|
- vLLM Releases
|
||||||
|
- Ollama Releases
|
||||||
|
- LiteLLM Releases
|
||||||
|
- Qdrant Blog
|
||||||
|
- Weaviate Blog
|
||||||
|
- pgvector Releases
|
||||||
|
|
||||||
|
### Agents IA & outils développeurs
|
||||||
|
|
||||||
|
- GitHub Copilot Changelog
|
||||||
|
- GitHub Blog
|
||||||
|
- VS Code Blog
|
||||||
|
- Cursor Changelog
|
||||||
|
- JetBrains AI Blog
|
||||||
|
- Sourcegraph Blog
|
||||||
|
- Continue.dev Releases
|
||||||
|
- Stack Overflow Trends (LLM & AI tags)
|
||||||
|
- Dev.to (search "AI engineering")
|
||||||
|
|
||||||
|
### Platform AI & MLOps en entreprise
|
||||||
|
|
||||||
|
- MLflow Blog / Releases
|
||||||
|
- Databricks AI Blog
|
||||||
|
- AWS SageMaker Blog
|
||||||
|
- Google Vertex AI Blog
|
||||||
|
- Microsoft Azure AI Blog
|
||||||
|
- BentoML Releases
|
||||||
|
- Seldon Blog
|
||||||
|
- Tecton Blog (feature platform)
|
||||||
|
- Feast Releases (feature store)
|
||||||
|
- Arize Blog (ML observability)
|
||||||
|
- Domino Data Lab Blog
|
||||||
|
- Vectara Blog (search & retrieval infrastructure)
|
||||||
|
|
||||||
|
### Sécurité, RGPD & gouvernance
|
||||||
|
|
||||||
|
- CNIL
|
||||||
|
- LINC CNIL
|
||||||
|
- ANSSI
|
||||||
|
- ENISA
|
||||||
|
- NIST AI
|
||||||
|
- OWASP Top 10 for LLM Applications
|
||||||
|
- AI Incident Database
|
||||||
|
|
||||||
|
### Médias et newsletters à utiliser avec prudence
|
||||||
|
|
||||||
|
- The Batch
|
||||||
|
- Latent Space
|
||||||
|
- Import AI
|
||||||
|
- MIT Technology Review AI
|
||||||
|
- The Decoder
|
||||||
|
- VentureBeat AI
|
||||||
|
|
||||||
|
Règle importante :
|
||||||
|
les médias et newsletters servent à détecter des signaux, mais il faut rechercher la source primaire avant d’intégrer une information importante.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Mapping Sources → OKR Q2
|
||||||
|
|
||||||
|
Prioriser les sources selon les OKRs Q2 actifs :
|
||||||
|
|
||||||
|
| OKR | Focus | Sources prioritaires |
|
||||||
|
|---|---|---|
|
||||||
|
| **O1-KR1** : Équipe IA-augmentée | Patterns d’intégration IA, dev workflows, agents pratiques | LangChain, LlamaIndex, Anthropic Docs, OpenAI Cookbook, GitHub Blog |
|
||||||
|
| **O1-KR2** : PAI dev opérationnelle | Infra IA, MLOps, deployment, feature store, monitoring | MLflow, Databricks, SageMaker, Vertex AI, BentoML, Arize, Feast, Tecton |
|
||||||
|
| **O1-KR3** : Support assisté | Agents IA, RAG, retrieval, evaluations | Vectara, BrainTrust, Anthropic Prompt Eng, LlamaIndex |
|
||||||
|
| **O2-KR2** : Bases techniques | Architecture, cloud, DevOps, infra | AWS Blog, Google Cloud Blog, Databricks, modal Labs, Supabase |
|
||||||
|
|
||||||
|
Ne conserver dans la note que les sujets alignés sur au moins un OKR, sauf si impact sécurité/RGPD majeur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Critères de sélection
|
||||||
|
|
||||||
|
Ne retenir qu’un sujet s’il répond à au moins un de ces critères :
|
||||||
|
|
||||||
|
- impact direct sur les pratiques produit ou tech ;
|
||||||
|
- nouveauté exploitable par une équipe ;
|
||||||
|
- évolution importante d’un modèle, d’une API ou d’un outil ;
|
||||||
|
- impact sécurité, RGPD ou gouvernance IA ;
|
||||||
|
- évolution importante des agents IA ;
|
||||||
|
- opportunité d’expérimentation concrète ;
|
||||||
|
- changement de prix, limite, licence ou condition d’utilisation ;
|
||||||
|
- impact potentiel pour une Platform AI (infra, monitoring, deployment, feature store) ;
|
||||||
|
- impact potentiel pour une entreprise tech d’environ 100 personnes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Scoring des informations
|
||||||
|
|
||||||
|
Chaque information repérée doit être notée de 0 à 5.
|
||||||
|
|
||||||
|
| Score | Signification |
|
||||||
|
|---:|---|
|
||||||
|
| 5 | À intégrer absolument |
|
||||||
|
| 4 | Très pertinent |
|
||||||
|
| 3 | Pertinent mais secondaire |
|
||||||
|
| 2 | Bruit potentiel |
|
||||||
|
| 1 | Hors sujet ou trop marketing |
|
||||||
|
| 0 | À ignorer |
|
||||||
|
|
||||||
|
Ne conserver dans la note finale que les sujets notés **4 ou 5**, sauf exception justifiée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Format de sortie attendu
|
||||||
|
|
||||||
|
Créer une note Markdown dans :
|
||||||
|
|
||||||
|
```text
|
||||||
|
80_sources/tech-ia/YYYY-MM-DD-veille-tech-ia.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## Modèle de notes à sortir
|
||||||
|
|
||||||
|
respecete le modele 99-templates/note-veille-tech-ia.md
|
||||||
|
|
||||||
|
## Règles de rédaction
|
||||||
|
|
||||||
|
- Écrire en français.
|
||||||
|
- Être synthétique.
|
||||||
|
- Ne pas être exhaustif.
|
||||||
|
- Prioriser les informations utiles pour décider ou agir.
|
||||||
|
- Distinguer les annonces confirmées des hypothèses.
|
||||||
|
- Signaler les incertitudes.
|
||||||
|
- Citer les sources.
|
||||||
|
- Privilégier les sources primaires.
|
||||||
|
- Éviter les formulations vagues comme “à suivre de près” sans explication.
|
||||||
|
- Toujours proposer des impacts concrets ou des actions recommandées.
|
||||||
207
40-playbooks/veille-mensuelle-emploi-devs.md
Normal file
207
40-playbooks/veille-mensuelle-emploi-devs.md
Normal file
|
|
@ -0,0 +1,207 @@
|
||||||
|
# Veille Mensuelle — Devs & Marché Emploi (Playbook 2/2)
|
||||||
|
|
||||||
|
## Objectif
|
||||||
|
|
||||||
|
Produire chaque mois une veille synthétique sur l'impact AI + agents sur les développeurs, le marché emploi, et l'évolution des rôles.
|
||||||
|
|
||||||
|
Cette veille alimente les décisions CTO/Codir sur :
|
||||||
|
- Stratégie hiring (entry-level vs senior, reskilling)
|
||||||
|
- Structure équipes (rôles, responsabilités à l'ère agents)
|
||||||
|
- Compensation (salaires AI-aware vs traditionnel)
|
||||||
|
- Carrière devs (skills critique, évolution rôles)
|
||||||
|
- Compétitivité produit (talent retention, attrition risk)
|
||||||
|
|
||||||
|
Elle s'adresse à un **CTO/DSI dans une entreprise tech ~100 personnes** qui doit comprendre comment agents impactent sa base talent et adapter sa stratégie.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Période analysée
|
||||||
|
|
||||||
|
Analyser les **4 dernières semaines** (avant le 1er du mois).
|
||||||
|
|
||||||
|
Inclure données plus anciennes si utiles pour trend long-terme (salaires 2024→2026, job postings 6 mois, etc.).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sources à privilégier
|
||||||
|
|
||||||
|
Prioriser sources primaires fiables et quantifiées :
|
||||||
|
|
||||||
|
### Emploi & Salaires
|
||||||
|
|
||||||
|
- LinkedIn Salary Data / Salary Insights
|
||||||
|
- Levels.fyi (tech comp data)
|
||||||
|
- Blind (engineer sentiment)
|
||||||
|
- Glassdoor (employer reviews + salary)
|
||||||
|
- ZipRecruiter (job postings trends)
|
||||||
|
- Indeed (US hiring trends)
|
||||||
|
- Stack Overflow Developer Survey (annual)
|
||||||
|
- GitHub Octoverse (developer activity + sentiment)
|
||||||
|
|
||||||
|
### Impact AI sur Devs
|
||||||
|
|
||||||
|
- GitHub's annual Copilot adoption reports
|
||||||
|
- Anthropic's Agentic Coding Trends Report (annual)
|
||||||
|
- OpenAI usage reports + API trends
|
||||||
|
- Morgan Stanley research (AI impact on dev jobs)
|
||||||
|
- McKinsey / BCG reports (tech labor transformation)
|
||||||
|
- CNN Business, Rest of World (popular coverage)
|
||||||
|
|
||||||
|
### Skills & Certification
|
||||||
|
|
||||||
|
- O'Reilly Learning Platform data (skill trends)
|
||||||
|
- Coursera/Udemy trends (skill demand)
|
||||||
|
- LinkedIn Skills Index (most-searched skills)
|
||||||
|
- HackerRank State of Tech Hiring (skill requirements)
|
||||||
|
|
||||||
|
### Market & Product Strategy
|
||||||
|
|
||||||
|
- VentureBeat (hiring patterns in tech)
|
||||||
|
- TechCrunch (hiring announcements, layoffs)
|
||||||
|
- Blind / Reddit r/cscareerquestions (sentiment, real data)
|
||||||
|
- Dice / Robert Half (IT salary guide)
|
||||||
|
|
||||||
|
### Team Dynamics & Org Design
|
||||||
|
|
||||||
|
- First Round Review (org design, scaling teams)
|
||||||
|
- A16Z blog (team structure + growth)
|
||||||
|
- Reforge articles (product, management lessons)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Critères de Sélection
|
||||||
|
|
||||||
|
Ne retenir qu'un sujet s'il répond à **au moins un** de ces critères :
|
||||||
|
|
||||||
|
- **Impact direct sur hiring strategy** (salaires, entry-level compression, AI-skill premium)
|
||||||
|
- **Evidence d'évolution rôles** (seniors → architects, juniors → agent supervisors)
|
||||||
|
- **Data quantifiée sur marché emploi** (job postings +/–%, salaries, attrition)
|
||||||
|
- **Trend carrière non-obvie** (skill bifurcation, talent drought, compensation inversion)
|
||||||
|
- **Impact retention/attrition** (devs leaving for AI-native roles, upskilling investments)
|
||||||
|
- **Team structure implications** (fewer entry, more senior, what's the ratio now?)
|
||||||
|
- **Compétitivité talent vs competitors** (AI-native startups pulling talent from incumbents)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Scoring des Informations
|
||||||
|
|
||||||
|
Chaque sujet noté **0 à 5** :
|
||||||
|
|
||||||
|
| Score | Signification |
|
||||||
|
|---:|---|
|
||||||
|
| 5 | À intégrer dans hiring/org strategy immédiatement |
|
||||||
|
| 4 | Très pertinent, impacts long-terme (6–12 mois) |
|
||||||
|
| 3 | Pertinent mais secondaire, observer trend |
|
||||||
|
| 2 | Bruit potentiel ou spéculatif |
|
||||||
|
| 1 | Marketing ou hors sujet |
|
||||||
|
| 0 | À ignorer |
|
||||||
|
|
||||||
|
**Ne conserver que scores 4–5**, sauf si trend contraire à hypothèses (red flag).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Format de Sortie Attendu
|
||||||
|
|
||||||
|
Créer une note Markdown dans :
|
||||||
|
|
||||||
|
```text
|
||||||
|
80-sources/marche-emploi/YYYY-MM-01-veille-emploi-devs.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Exemple : `80-sources/marche-emploi/2026-05-01-veille-emploi-devs.md`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Modèle de Note à Produire
|
||||||
|
|
||||||
|
Respecter le template : `99-templates/note-veille-emploi-devs.md` (à créer)
|
||||||
|
|
||||||
|
Template inclut sections :
|
||||||
|
- Synthèse exécutive (pour Codir, 5–10 lignes)
|
||||||
|
- Top 5 signaux (salaires, hiring, skills, sentiment, team structure)
|
||||||
|
- Impacts par rôle (Devs juniors, Devs seniors, Leads, PMs, CTOs)
|
||||||
|
- Data quantifiée + trends
|
||||||
|
- Implications pour hiring strategy
|
||||||
|
- Implications pour team structure
|
||||||
|
- Implications pour compensation policy
|
||||||
|
- Actions recommandées (recrutement, upskilling, org design)
|
||||||
|
- Questions à creuser
|
||||||
|
- Sources avec dates
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Règles de Rédaction
|
||||||
|
|
||||||
|
- Écrire en français.
|
||||||
|
- **Prioriser data quantifiée** : chiffres > opinions (Blind reviews = opinion, salaires Levels = data)
|
||||||
|
- Distinguer **fait établi** vs **trend émergent** vs **spéculation**
|
||||||
|
- Signaler les **incertitudes** explicitement
|
||||||
|
- Citer les sources primaires (pas aggregators)
|
||||||
|
- Éviter "soft skill" buzzwords : "leadership", "culture fit" = flou. Préférer : "agent orchestration", "systems design", "scope ownership"
|
||||||
|
- **Toujours proposer action concrète** : "salaires +15% AI-aware" = action = remonter salaire entry AI-track
|
||||||
|
- Ne pas être exhaustif : filter par pertinence CTO/Codir
|
||||||
|
- Tone = direct, fact-based, occasionally challenging (si trend est contre vos assomptions, le signaler)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Cadence et Temps d'Exécution
|
||||||
|
|
||||||
|
**Quand :** 1er du mois, matin
|
||||||
|
**Durée estimée :** 60–90 min total
|
||||||
|
- Scan sources (30 min)
|
||||||
|
- Rédaction + analyse (45 min)
|
||||||
|
- Review + publication (15 min)
|
||||||
|
|
||||||
|
**Ou :** Faire en 2 sessions (30 min scan jeudi, 60 min rédaction samedi)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Checklist d'Exécution
|
||||||
|
|
||||||
|
- [ ] Parcourir LinkedIn Salary Data (US + émergent pays)
|
||||||
|
- [ ] Consulter Levels.fyi trends (comp evolution)
|
||||||
|
- [ ] Lire Blind posts du mois (sentiment engineer, attrition signals)
|
||||||
|
- [ ] Checker GitHub Octoverse data (participation, language trends)
|
||||||
|
- [ ] Lire 2–3 articles Morgan Stanley / McKinsey (macro trends)
|
||||||
|
- [ ] Scan ZipRecruiter job postings (trends titres, skills, demand)
|
||||||
|
- [ ] Chercher "AI agents developer impact 2026" + "dev job market 2026" (news)
|
||||||
|
- [ ] Noter top 5 signaux + scores
|
||||||
|
- [ ] Rédiger note avec impacts par rôle
|
||||||
|
- [ ] Proposer 3–5 actions concrètes
|
||||||
|
- [ ] Publier dans `80-sources/marche-emploi/`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Pièges à Éviter
|
||||||
|
|
||||||
|
- **Hype vs reality** : Beaucoup de bruit sur "AI eliminates devs" (faux). Prioriser data quantifiée.
|
||||||
|
- **Selection bias** : LinkedIn et Blind surreprésentent SV et senior devs. Adapter pour réalité France.
|
||||||
|
- **Lag dans data** : Salaires Levels = 3 mois old. Expliquer quand utilisant.
|
||||||
|
- **Corrélation ≠ causalité** : Si junior hiring ↓ et Copilot adoption ↑, ne pas assumer causalité (peut être cyclique economique).
|
||||||
|
- **Too prescriptive** : Veille ≠ stratégie. Proposer observations + actions, pas décisions (Codir decide).
|
||||||
|
- **Forgot soft context** : Embauches tech ≠ que skill; culture, mission, startup/scale aussi compte. Nuancer.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Exemple Tempo (Dimanche 1er du mois)
|
||||||
|
|
||||||
|
```
|
||||||
|
09:00–09:30 : Scan LinkedIn Salary + Levels.fyi trends
|
||||||
|
09:30–10:00 : Lire Blind posts (sentiment) + GitHub Octoverse
|
||||||
|
10:00–10:30 : McKinsey/Morgan Stanley report skim + ZipRecruiter
|
||||||
|
10:30–11:15 : Rédiger note veille + impacts
|
||||||
|
11:15–11:30 : Formatter + publier
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Lien avec Veille Tech & IA Hebdo
|
||||||
|
|
||||||
|
- **Veille Tech & IA (hebdo)** = "what tools/frameworks shipped, impacts teams accel"
|
||||||
|
- **Veille Emploi Devs (mensuel)** = "what's happening to career, hiring, talent, org"
|
||||||
|
|
||||||
|
Deux lenses différentes : tech + business. Complementaires, pas redondant.
|
||||||
|
|
||||||
|
Exemple :
|
||||||
|
- Tech veille : "Claude Managed Agents dreaming shipped" → devs use it
|
||||||
|
- Emploi veille : "AI-savvy devs earn +$25K, entry-level hiring –45%" → hiring strategy changes
|
||||||
435
80-sources/marche-emploi/2026-05-01-veille-emploi-devs.md
Normal file
435
80-sources/marche-emploi/2026-05-01-veille-emploi-devs.md
Normal file
|
|
@ -0,0 +1,435 @@
|
||||||
|
# Veille Emploi & Devs - 2026-05-01
|
||||||
|
|
||||||
|
## Synthèse exécutive
|
||||||
|
|
||||||
|
Marché dev reprend mais **entry-level toujours cassé** : postings dev +15% depuis mi-2025, mais entry-level **–45% vs 2023 peak**. AI-savvy devs gagnent **+$25K premium** ($90K–$130K entry vs $65K–$85K traditionnel). GitHub Copilot (4.7M users, 51% faster, $967/mois value/dev) devient standard. Juniors sans AI-skills obsoletes; seniors ayant skill orchestration agents demandés.
|
||||||
|
|
||||||
|
**Red flag :** Pipeline talent fragile. Bootcamp grads hitting mur, training programs rares. Hiring marché = "ready now" precision, pas formation. **Opportunité :** Reskill existing juniors on agents (cheaper, faster que external hiring, culture retention).
|
||||||
|
|
||||||
|
**Implication Codir :** Inverser team composition (moins juniors, plus seniors + agents). Revoir compensation policy (AI-aware premium). Investir internal academy agents (pas d'offre marché).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Top 5 des Signaux Forts
|
||||||
|
|
||||||
|
| Sujet | Importance | Data clé | Implication hiring / org | Action recommandée |
|
||||||
|
|---|---:|---|---|---|
|
||||||
|
| Entry-level hiring collapse | Fort | –45% vs 2023, training programs rare | Junior pipeline = 0, reskill existing or starve | Build internal onboarding agents-first, not code-first |
|
||||||
|
| AI-savvy salary premium | Fort | $90K–$130K vs $65K–$85K (+$25K–$45K) | Attrition risk seniors; entry tier bifurcated | Raise salary bands for AI-aware, decide positioning |
|
||||||
|
| GitHub Copilot mainstream | Fort | 4.7M users, 51% faster, 88% suggestion retention | Code quality baseline rises, hiring bar up | Assume all devs use Copilot, interview for agent skills |
|
||||||
|
| Skills shift : agents = new core | Moyen | Systems design, agent orch, cloud arch in-demand; boilerplate coding out | Senior scarcity, junior devaluation | Invest systems design training, agent patterns curriculum |
|
||||||
|
| Team composition inversion | Moyen | Optimal = 20% juniors, 50% mid, 30% senior (agents do routine) | Hiring north = seniors, south = juniors | Adjust org design, mentor ratio (seniors coach mids on agents) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Impact par Rôle
|
||||||
|
|
||||||
|
### Développeurs Juniors
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
Entry-level postings –45% vs 2023 peak, but market recovering (+15% overall). Bootcamp grads struggling to land first role. AI agents do routine coding (boilerplate, tests, bug fixes), which was traditional junior onboarding. **Juniors are competing with agents for the same work.**
|
||||||
|
|
||||||
|
**Salaire :**
|
||||||
|
- Traditional entry : $65K–$85K
|
||||||
|
- AI-savvy entry : $90K–$130K
|
||||||
|
- **Bifurcation:** strong juniors with agent knowledge price high; others struggle to find role
|
||||||
|
- Market signaling : "basic junior" skills obsolete
|
||||||
|
|
||||||
|
**Skills critiques :**
|
||||||
|
- Agent oversight (not code writing)
|
||||||
|
- Code review for agent output (validation, security)
|
||||||
|
- Prompt engineering for agents
|
||||||
|
- Systems design (learn from agents? or gaps?)
|
||||||
|
- Git workflows, testing mindset
|
||||||
|
- ~~Boilerplate coding~~ (agents handle)
|
||||||
|
- ~~Pixel-perfect frontend~~ (Figma → code agents)
|
||||||
|
|
||||||
|
**Sentiment / Attrition :**
|
||||||
|
- Bootcamp grads : demoralized ("AI took my job before I had it")
|
||||||
|
- Employed juniors : upskilled rapidly or feel obsolete
|
||||||
|
- Blind/Reddit sentiment : "junior roles don't exist anymore"
|
||||||
|
- Risk : talent exodus to other fields, or desperate acceptance of low-skill roles elsewhere
|
||||||
|
|
||||||
|
**Hiring outlook :**
|
||||||
|
- **Short-term (Q2 2026) :** Entry hiring stays suppressed. Companies hiring "ready now" senior agents-expert.
|
||||||
|
- **Medium-term (H2 2026) :** Hiring may recover IF reskilling programs prove ROI, but pure external junior hiring risky
|
||||||
|
- **Long-term :** Bifurcated market. Top juniors (AI-aware) absorb entry roles; others (non-AI) pushed to other sectors
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
1. **If you're hiring :** Don't recruit external juniors; recruit seniors or reskill internals
|
||||||
|
2. **If you have juniors :** Mandatory agents curriculum (week 1 onboarding), pivot to agent supervision + systems design
|
||||||
|
3. **If you're junior :** Bootcamp alone insufficient. Seek agent-first programs or internal ramps.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Développeurs Mid-Level
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
Mid-level hiring steady, recovering. Mid-levels are the "sweet spot" : agents handle routine, mids orchestrate + deliver features. No crisis, but upskilling pressure.
|
||||||
|
|
||||||
|
**Salaire :**
|
||||||
|
- Traditional mid : $100K–$140K
|
||||||
|
- Senior-track mid : $120K–$160K
|
||||||
|
- **Inflation minimal** ; market tight but no runaway comp
|
||||||
|
|
||||||
|
**Skills critiques :**
|
||||||
|
- Agent orchestration (multi-step workflows, debugging agent failures)
|
||||||
|
- Systems design (midway to senior)
|
||||||
|
- Cloud architecture
|
||||||
|
- Team coordination (agents + humans)
|
||||||
|
- Incident response (agent failures in prod)
|
||||||
|
- Security review (agent-generated code)
|
||||||
|
|
||||||
|
**Sentiment / Attrition :**
|
||||||
|
- Generally positive : work becomes more strategic (less grind, more design)
|
||||||
|
- But : orchestration complexity new overhead
|
||||||
|
- Risk of feeling "supervising bots, not building" (psychological impact)
|
||||||
|
|
||||||
|
**Hiring outlook :**
|
||||||
|
- **Strong demand.** Mid-levels are the lever for team scaling with agents.
|
||||||
|
- Easier to hire external mids than juniors or seniors
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
1. Invest in agent orchestration training (LangGraph, multi-agent patterns)
|
||||||
|
2. Create "agent orchestration" role clarity (what does this dev own?)
|
||||||
|
3. Monitor sentiment (supervision fatigue = real risk)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Développeurs Seniors / Tech Leads
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
Senior demand **high** (agents need human architects). But supply constrained. Salary inflation significant. Competition fierce for senior agents-expert talent.
|
||||||
|
|
||||||
|
**Salaire :**
|
||||||
|
- Traditional senior : $150K–$200K+
|
||||||
|
- Senior + agent expertise : $180K–$250K+
|
||||||
|
- **Premium :** +$30K–$50K for agents-expert architects
|
||||||
|
- C-level engineering roles pulling talent (CTO, VP Eng)
|
||||||
|
|
||||||
|
**Skills critiques :**
|
||||||
|
- Multi-agent system design (complex orchestration)
|
||||||
|
- Governance & safety (agents at scale = risk)
|
||||||
|
- Cost optimization (token budgets, compute efficiency)
|
||||||
|
- Security (agent code review, guardrails)
|
||||||
|
- Team architecture (how many agents per senior? supervision model?)
|
||||||
|
- Hiring strategy (how to attract senior talent in agent era?)
|
||||||
|
|
||||||
|
**Sentiment / Attrition :**
|
||||||
|
- **Opportunity mindset :** agents = new frontier, exciting
|
||||||
|
- But : **validation overhead risk** (–19% some seniors due to code review friction)
|
||||||
|
- **Headhunting pressure :** AI-native startups aggressively recruiting senior agents architects
|
||||||
|
- **Burnout risk :** If poorly supported, seniors feel "firefighting agent failures" instead of architecture
|
||||||
|
|
||||||
|
**Hiring outlook :**
|
||||||
|
- **Very high demand,** but **supply scarce.** External hiring = expensive ($200K+ total comp).
|
||||||
|
- Internal promotion from mid-level = primary source
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
1. **Retention urgency :** Seniors are flight risk if compensation/mission unclear. Lock in equity, mission clarity.
|
||||||
|
2. **Invest in systems design training** for high-performing mids (succession pipeline)
|
||||||
|
3. **Competitive compensation :** Monitor market ($180K–$250K for agents expert). Underpay = attrition.
|
||||||
|
4. **Define role clearly :** "Senior architect" in agent era ≠ old "senior dev". Clarity reduces frustration.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Chefs de Projets / Product Managers
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
PM roles stable, but requirements changing. PM must understand agent capabilities/limitations to scope realistic roadmaps. Delivery speed up, estimation difficulty up.
|
||||||
|
|
||||||
|
**Impact :**
|
||||||
|
- Feature delivery : **–70% timeline** (weeks → days for complex features)
|
||||||
|
- Quality variance : agents great routine, risky novel logic
|
||||||
|
- Scope creep risk : faster delivery tempts over-ambitious roadmaps
|
||||||
|
- Team dynamics : agents + humans = coordination complexity (more sync points, not fewer)
|
||||||
|
|
||||||
|
**Skills demanded :**
|
||||||
|
- Agent capability scoping (what can/can't agents do?)
|
||||||
|
- Risk assessment (agent failures in prod = user-facing)
|
||||||
|
- Roadmap estimation with agents (less predictable than humans)
|
||||||
|
- Team orchestration (agents + humans working together)
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
1. Upskill on agent patterns (LangGraph, multi-step workflows)
|
||||||
|
2. Create estimation framework : "agent tasks" vs "human tasks" (different velocity)
|
||||||
|
3. Plan more, scope aggressive (deliver faster, learn faster)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Marché Emploi : Données Quantifiées
|
||||||
|
|
||||||
|
### Job Postings & Hiring Trends
|
||||||
|
|
||||||
|
| Métrique | Trend | Data source |
|
||||||
|
|---|---|---|
|
||||||
|
| Job postings dev (total) | +15% since mid-2025 (recovery) | ZipRecruiter / Indeed |
|
||||||
|
| Entry-level postings | –45% vs 2023 peak (suppressed) | ZipRecruiter |
|
||||||
|
| Senior/lead postings | +25% vs 2023 (high demand) | LinkedIn / ZipRecruiter |
|
||||||
|
| Hiring pace | Slowing slightly (precision hiring, not volume) | Blind, company reports |
|
||||||
|
| **Market size 2026–2029** | $24B (2024) → $61B (2029), +20% CAGR | Morgan Stanley / McKinsey |
|
||||||
|
|
||||||
|
**Interpretation :** Market growing fast (+20%/an), but **entry-level suppressed** (agents displace routine work). Senior talent increasingly scarce. Hiring = precision (revenue-driving roles), not broad junior pipeline.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Salaires & Compensation
|
||||||
|
|
||||||
|
| Profil | Salaire USD | Premium AI | Trend | Source |
|
||||||
|
|---|---:|---:|---|---|
|
||||||
|
| Entry-level (non-AI) | $65K–$85K | – | Flat or ↓ (supply up, entry jobs ↓) | Levels.fyi, ZipRecruiter |
|
||||||
|
| Entry-level (AI-aware) | $90K–$130K | +$25K–$45K | ↑ (demand > supply) | Levels.fyi |
|
||||||
|
| Mid-level (architecture) | $120K–$160K | +$15K–$25K | ↑ (agent expertise) | Levels.fyi |
|
||||||
|
| Senior (agent orchestration) | $180K–$250K+ | +$30K–$50K | ↑↑ (scarce) | Levels.fyi, LinkedIn |
|
||||||
|
| **GitHub Copilot users (avg)** | **$95.3K** (Feb 2026) | **~$25K** (estimated) | **Proxy for AI-aware salary** | ZipRecruiter |
|
||||||
|
|
||||||
|
**Interpretation :** Clear bifurcation. AI-savvy devs earn $25K–$50K more. Traditional junior track = declining comp. Senior agent-expert = highest demand + highest pay.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Skills In-Demand & Trending
|
||||||
|
|
||||||
|
| Skill | Trend | Why (AI agent shift?) | Hiring demand |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Python | ↑ | Agents + AI frameworks | Very high |
|
||||||
|
| TypeScript / Node.js | → | Still web/API standard | Very high |
|
||||||
|
| Systems design | ↑↑ | Agents need architecture, less junior coding | Very high |
|
||||||
|
| Agent orchestration | ↑↑↑ (new) | Multi-agent patterns (LangGraph, etc.) | Emerging high |
|
||||||
|
| Cloud architecture | ↑ | Infrastructure for agents, multi-cloud | High |
|
||||||
|
| Cybersecurity / secure coding | ↑ | Agent-generated code = audit risk | High |
|
||||||
|
| DevOps / SRE | ↑ | Agent monitoring ≠ monolith monitoring | High |
|
||||||
|
| Rust (systems) | ↑ | Infrastructure, performance-critical | Moderate |
|
||||||
|
| ~~Boilerplate coding~~ | ↓↓ | Agents handle | Low |
|
||||||
|
| ~~Pixel-perfect frontend~~ | ↓ | Figma → code agents | Moderate (UI still human) |
|
||||||
|
| ~~Routine bug fixing~~ | ↓ | Agents handle | Low |
|
||||||
|
|
||||||
|
**Interpretation :** Architect + systems design skills premium. Routine coding skills depreciate. Agents create demand for "how to supervise agents" knowledge (new skillset).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Talent Sentiment & Attrition
|
||||||
|
|
||||||
|
| Signal | Data | Implication |
|
||||||
|
|---|---|---|
|
||||||
|
| Junior morale (Blind, Reddit) | "entry-level jobs don't exist", bootcamp grads struggling | Attrition to other fields? Reskilling inertia? |
|
||||||
|
| Senior burnout (agent oversight?) | "validating agent code is tedious", mixed sentiment on agents | Validation overhead real. Tool + process improvements needed. |
|
||||||
|
| Bootcamp grad employment | Placement rates down 30–40% vs 2023 | Pipeline fragile. Bootcamps need to teach agents-first. |
|
||||||
|
| Mid-level satisfaction | Generally positive (less grind, more strategy) | Retention stable if compensation fair. |
|
||||||
|
| Avg tenure senior roles | Slight ↓ (headhunting pressure from AI startups) | Senior attrition risk if underpaid or misaligned. |
|
||||||
|
|
||||||
|
**Interpretation :** Juniors demoralized (pipeline crisis). Seniors at flight risk (attractive market). Mids stable. Overall : talent market bifurcated, not unified.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implications pour Stratégie Hiring
|
||||||
|
|
||||||
|
### Entry-Level Hiring Strategy
|
||||||
|
|
||||||
|
**Current state :**
|
||||||
|
- Hiring external juniors = high-risk, low-reward (no role fit, training overhead)
|
||||||
|
- Bootcamp pipeline broken (–45% postings)
|
||||||
|
- Training programs rare (companies hire "ready now")
|
||||||
|
|
||||||
|
**Challenge :**
|
||||||
|
- Agents do routine coding (traditional junior work)
|
||||||
|
- Juniors can't learn coding-by-doing anymore (no grind tasks)
|
||||||
|
- Market expects "junior able to supervise agents day 1" = unrealistic
|
||||||
|
|
||||||
|
**Recommendation :**
|
||||||
|
1. **Stop external junior hiring** (at least through 2026). Use freed budget for senior hires + reskilling.
|
||||||
|
2. **Build internal junior program** :
|
||||||
|
- Recruit **interns or bootcamp-adjacent talent** (cheaper, lower bar)
|
||||||
|
- Curriculum = agents-first (week 1 : Copilot, LangGraph, prompt engineering)
|
||||||
|
- Not "write CRUD API" but "supervise agent writing CRUD API"
|
||||||
|
- 12-week ramp (vs 6-month traditional), then productive
|
||||||
|
3. **Or : partner bootcamp** (negotiate curriculum focus on agents)
|
||||||
|
|
||||||
|
**Timeline :** Q2 2026 design, Q3 2026 launch first cohort.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Mid-Level Hiring Strategy
|
||||||
|
|
||||||
|
**Current state :**
|
||||||
|
- External mid hiring = viable (supply better than junior, demand high)
|
||||||
|
- Mid-level = "sweet spot" for agent era (agents + human orchestration)
|
||||||
|
|
||||||
|
**Demand :**
|
||||||
|
- Agent orchestration experience (multi-step workflows, error handling)
|
||||||
|
- Systems design (mid-level arch thinking)
|
||||||
|
- Team leadership (supervising agents + juniors)
|
||||||
|
|
||||||
|
**Recommendation :**
|
||||||
|
1. **Hire for "agent orchestration" explicitly** (not generic "mid-level dev")
|
||||||
|
2. **Interview questions should include :**
|
||||||
|
- "How do you debug a multi-agent workflow?"
|
||||||
|
- "Design a system where agents handle X, humans handle Y"
|
||||||
|
- "How do you validate agent-generated code?"
|
||||||
|
3. **Look for candidates with Claude / ChatGPT / Copilot experience** (signal of agent-aware thinking)
|
||||||
|
|
||||||
|
**Salary :** $120K–$160K depending on agent expertise.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Senior Hiring Strategy
|
||||||
|
|
||||||
|
**Current state :**
|
||||||
|
- External senior hiring = expensive but essential (supply < demand)
|
||||||
|
- Agent-architect expertise = rare, premium-priced
|
||||||
|
|
||||||
|
**Demand :**
|
||||||
|
- Multi-agent system design (orchestration, safety, cost)
|
||||||
|
- Technical strategy (agents vs traditional code trade-offs)
|
||||||
|
- Team architecture (how many agents per human?)
|
||||||
|
- Hiring & mentoring (building agent-era teams)
|
||||||
|
|
||||||
|
**Recommendation :**
|
||||||
|
1. **Hire for "agent system architect" roles** (new job title emerging)
|
||||||
|
2. **Compensation :** $180K–$250K+ (market competitive)
|
||||||
|
3. **Look for :**
|
||||||
|
- Claude / GPT API experience (not just Copilot)
|
||||||
|
- Proven agent deployment in prod (rare but exists)
|
||||||
|
- Leadership (shipping teams, not solo IC)
|
||||||
|
4. **Poach from :** AI-native startups, OpenAI/Anthropic partners, research labs
|
||||||
|
5. **Retention :** Lock in equity, mission clarity, compensation review (agents-expert premium = real)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Compensation Policy Update
|
||||||
|
|
||||||
|
**Current salary bands :**
|
||||||
|
(Assume your bands before reading this)
|
||||||
|
|
||||||
|
**Market shift :**
|
||||||
|
- AI-savvy premium = +$25K–$50K real, not perception
|
||||||
|
- Senior agent architects = highest demand, highest pay
|
||||||
|
- Entry-level bifurcation (AI-aware vs traditional)
|
||||||
|
|
||||||
|
**Recommendation :**
|
||||||
|
1. **Raise entry-level ceiling** (if you hire AI-aware juniors) : $85K → $100K+ (to attract bootcamp grads willing to ramp)
|
||||||
|
2. **Raise mid-level range** : Add "agent orchestration expert" track above mid baseline (+$15K–$25K)
|
||||||
|
3. **Raise senior ceiling** : $200K → $230K+ for agent architects (external benchmark = $250K)
|
||||||
|
4. **Create explicit "AI-aware" tier** in your levels (communicate market reality)
|
||||||
|
|
||||||
|
**Timing :** Q2 2026 audit, Q3 2026 implement (before H2 hiring sprint).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implications pour Structure Équipes
|
||||||
|
|
||||||
|
### Current Team Composition (estimated for 50-dev shop)
|
||||||
|
|
||||||
|
| Level | Headcount | % Team | Role |
|
||||||
|
|---|---:|---:|---|
|
||||||
|
| Junior | 25 | 50% | Routine coding, learning |
|
||||||
|
| Mid | 15 | 30% | Feature delivery, mentoring |
|
||||||
|
| Senior | 10 | 20% | Architecture, hiring, strategy |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Recommended Composition (Agent Era, same 50-dev shop)
|
||||||
|
|
||||||
|
| Level | Headcount | % Team | Role | Rationale |
|
||||||
|
|---|---:|---:|---|---|
|
||||||
|
| Junior | 10 | 20% | Agent supervision, code review, learning systems design | Agents do routine; juniors oversee + learn architecture. Fewer, but higher-skilled. |
|
||||||
|
| Mid | 25 | 50% | Feature delivery, agent orchestration, team coordination | Core delivery layer. Agents + mids = main velocity. |
|
||||||
|
| Senior | 15 | 30% | Architecture, agent system design, hiring, mentoring | Design multi-agent workflows. Build team. Grow mids. |
|
||||||
|
|
||||||
|
**Implications :**
|
||||||
|
- Hire differently : fewer juniors, more seniors + mids
|
||||||
|
- Mentor differently : seniors coach mids on "how to orchestrate agents", not "how to code"
|
||||||
|
- Onboard differently : juniors start with agents, not blank slate coding
|
||||||
|
|
||||||
|
**Timeline :** Transition over 6–12 months (organic promotion of strong mids, external senior hiring, junior hiring freeze).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Team Structure Evolution Needed
|
||||||
|
|
||||||
|
**Org Design :**
|
||||||
|
- Create "agent orchestration lead" role per squad (senior mid or staff engineer)
|
||||||
|
- Pair each agent system with 2–3 human supervisors (prevent 1-person bottleneck)
|
||||||
|
- Create "agent reliability team" (debugging, monitoring, incident response)
|
||||||
|
|
||||||
|
**Career Ladder :**
|
||||||
|
- **New titles :** "Senior Agent Architect" (vs "Senior Dev")
|
||||||
|
- **Mid path :** "Agent Orchestration Specialist" (track record of multi-agent systems)
|
||||||
|
- **Junior path :** "Agent Supervisor" (first role, learning systems design)
|
||||||
|
|
||||||
|
**Mentoring :**
|
||||||
|
- Senior = coaches mids on "how to scope agent tasks, design agent workflows"
|
||||||
|
- Mid = coaches juniors on "how to validate agent output, review code for logic errors"
|
||||||
|
- Not "here's how to write perfect code", but "here's how to work with AI"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Red Flags & Opportunities
|
||||||
|
|
||||||
|
### Red Flags
|
||||||
|
|
||||||
|
| Flag | Evidence | Risk | Mitigation |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Junior pipeline evaporating | Entry-level –45% vs 2023, bootcamps struggling | Can't grow talent internally, external hiring breaks down | Build internal reskilling track (week 1 agents curriculum), partner bootcamp on agent-first programs |
|
||||||
|
| Salary compression | AI-aware +$25K premium emerging, entry-level bifurcating | Attrition seniors? Or entry tier entirely obsolete? | Audit compensation, decide positioning (hire AI-aware premium or traditional track?) |
|
||||||
|
| Agent orchestration skill gap | No one trained, market has few experts | Hiring externals risky; internal upskilling slow | Invest 8–12 weeks in agent patterns workshop (LangGraph, prompt eng, multi-step workflows) |
|
||||||
|
| Validation overhead (seniors –19% productivity) | Some seniors slowed by agent code review | Burnout risk; seniors lose edge if too much validation | Tool investment (automated checkers for agent code), process (what should humans review vs skip?) |
|
||||||
|
| Headhunting pressure on seniors | AI startups aggressively recruiting | Attrition of best architects | Lock in equity, mission clarity, compensation survey (stay competitive $250K band) |
|
||||||
|
|
||||||
|
### Opportunities
|
||||||
|
|
||||||
|
| Opportunity | Why now | Expected benefit | Effort |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Reskill existing juniors on agents | Entry market broken, but internal talent exists, agents-first curriculum clear | Cheaper hiring ($15K onboarding vs $20K recruiting), culture retention, agents expertise | **Moyen** (4–8 weeks training, ongoing curriculum) |
|
||||||
|
| Acquire senior architect talent | High demand for agent design, budget freed from skipping external junior hiring | Build moat vs competitors on agent orchestration, attract future talent (reputation) | **Fort** (recruiting, offer $200K+, onboarding) |
|
||||||
|
| Invest in internal academy (agents) | No market training exists; bootcamps struggling to adapt | Become known for agent talent, attract top developers, competitive advantage | **Fort** (6 months build, ongoing delivery) |
|
||||||
|
| Adjust org design early (fewer juniors, more mids) | Trend clear, but competitors slow to adapt | Talent utilization optimization, more strategic work per person, culture shift to architecture | **Moyen** (org change is friction, but doable over 6 months) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Questions à Creuser
|
||||||
|
|
||||||
|
1. **Hiring strategy :** How do you build a junior pipeline when entry-level jobs vanish? Is internal reskilling realistic, or is bootcamp partnership necessary?
|
||||||
|
2. **Compensation :** Do you raise salary bands to match AI-aware market, or accept attrition of strong juniors to other fields?
|
||||||
|
3. **Team math :** If agents +30–50% productivity, and juniors can't learn coding anymore (no grind tasks), what's the optimal team ratio (juniors:mids:seniors)? Is 20% juniors realistic?
|
||||||
|
4. **Retention :** Which of your seniors are at flight risk (headhunting pressure)? How do you keep them (mission, comp, equity)?
|
||||||
|
5. **Culture :** Does "your senior became an architect of agent swarms" feel like promotion or job evolution? Is team excited or anxious?
|
||||||
|
6. **International :** Is this trend US-only (Levels.fyi, Blind = US-centric data) or happening in France / EU? Salary trends different?
|
||||||
|
7. **Competitors :** Are your competitors moving on this (reskilling, hiring seniors)? Or are you ahead of the curve?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## À Intégrer dans PKM
|
||||||
|
|
||||||
|
| Note | Action | Priorité |
|
||||||
|
|---|---|---|
|
||||||
|
| 20-areas/pro/management/hiring-strategy-2026 | **Créer :** Framework for agent-era hiring (junior internal ramp vs external senior hunt) | ⭐⭐⭐ |
|
||||||
|
| 20-areas/pro/management/compensation-2026 | **Audit :** Current salary bands vs market. Decision : AI-aware premium or traditional track? | ⭐⭐⭐ |
|
||||||
|
| 20-areas/pro/management/junior-pipeline | **Create :** Internal bootcamp curriculum (agents-first, 12 weeks, hire interns/early career) | ⭐⭐⭐ |
|
||||||
|
| 20-areas/pro/cto/team-structure-agent-era | **Document :** Ideal org composition (20% juniors, 50% mids, 30% seniors). Timeline for transition. | ⭐⭐ |
|
||||||
|
| 20-areas/pro/cto/senior-retention | **Plan :** Compensation + mission + equity review for agents-expert seniors (flight risk). | ⭐⭐ |
|
||||||
|
| 30-resources/management/reskilling-agents-curriculum | **Create :** 8–12 week curriculum for juniors : LangGraph, prompt eng, multi-step agents, validation patterns. | ⭐⭐ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sources Consultées
|
||||||
|
|
||||||
|
| Source | Éditeur | Date | Type |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| [2026 Agentic Coding Trends Report](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf) | Anthropic | May 2026 | Report |
|
||||||
|
| [Agentic Coding in 2026: AI's Impact on Software Development](https://www.timesofai.com/industry-insights/agentic-coding-in-software-development/) | Times of AI | 2026 | Article |
|
||||||
|
| [The demise of software engineering jobs has been greatly exaggerated](https://www.cnn.com/2026/04/08/tech/ai-software-developer-jobs) | CNN Business | April 2026 | News |
|
||||||
|
| [GitHub Copilot Statistics 2026](https://www.getpanto.ai/blog/github-copilot-statistics) | GetPanto | 2026 | Data |
|
||||||
|
| [Developer Job Market Recovery 2026: Data Analysis and Trends](https://pooya.blog/blog/software-dev-job-market-recovery-2026/) | Pooya Golchian | 2026 | Analysis |
|
||||||
|
| [Salary: Github Copilot (February, 2026) United States](https://www.ziprecruiter.com/Salaries/Github-Copilot-Salary) | ZipRecruiter | Feb 2026 | Data |
|
||||||
|
| [AI Impact on the Job Market in 2026: What the Data Shows](https://www.secondtalent.com/resources/ai-impact-job-market-2026/) | Second Talent | 2026 | Report |
|
||||||
|
| [Tech Job Market 2026: Trends, Skills, and Opportunities](https://legacy.anitab.org/blog/resources/tech-job-market-2026/) | AnitaB | 2026 | Article |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Actions pour le Mois Prochain
|
||||||
|
|
||||||
|
- [ ] Audit compensation vs market (Levels.fyi, LinkedIn)
|
||||||
|
- [ ] Sketch internal junior bootcamp (agents-first curriculum)
|
||||||
|
- [ ] Interview 3–5 senior candidates (understand agent-architect expectations)
|
||||||
|
- [ ] Sync with HR/People (hiring strategy shift, junior hiring freeze implications)
|
||||||
|
- [ ] Decide : internal ramp vs external hiring for juniors
|
||||||
|
|
@ -0,0 +1,344 @@
|
||||||
|
# Veille Tech & IA - Agents de Code & Marché Emploi - 2026-05-10
|
||||||
|
|
||||||
|
## Synthèse exécutive
|
||||||
|
|
||||||
|
**Agents de code transforment le travail dev, ne le tuent pas.** Productivité globale +31.4%, mais bimodale : juniors +10–30%, seniors –19% (overhead validation). GitHub Copilot (4.7M users, 51% plus rapide) et OpenAI Codex (GPT-5.5, agentic complet) deviennent standards. Anthropic pousse avec Managed Agents + "dreaming". Microsoft ajoute subagents Visual Studio.
|
||||||
|
|
||||||
|
**Marché explose malgré transformation :** dev jobs pas tués, réinventés. Marché logiciels : $24B (2024) → $61B (2029), +20% annuel. AI-savvy devs gagnent $90K–$130K entry-level vs $65K–$85K traditionnel. Entry-level hiring demeure bas (–45% vs 2023) mais recovery commence. **Skill shift majeur :** routine coding → AI oversight. Devs doivent apprendre agent orchestration + systems architecture.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Top 5 des signaux forts
|
||||||
|
|
||||||
|
| Sujet | Importance | Impacts | Donnée clé | Implication pour teams |
|
||||||
|
|---|---:|---|---|---|
|
||||||
|
| OpenAI Codex GPT-5.5 agentic GA | Fort | Productivité +30–50%, full code automation | #1 ranking mai 2026, multifile editing + git orchestration | Juniors compétitifs vs seniors sur tâches auto-able |
|
||||||
|
| Anthropic Claude Managed Agents "dreaming" | Fort | Self-improvement agents, memory continuity | 17x API growth YoY, 86% orgs deploy prod agents | Agents deviennent autonomes sans human steering |
|
||||||
|
| GitHub Copilot mainstream : 4.7M payants | Fort | 51% faster, 88% suggestion retention | $967/month value per dev, 3.6h saved/week | ROI T1 pour équipes 50+ devs |
|
||||||
|
| Inversion rôles : seniors doivent lever yeux | Moyen | Junior work automated, senior work = arch + AI oversight | AI-savvy seniors $90K–$130K entry-level | Transition carière nécessaire : coding → system design |
|
||||||
|
| Marché explose mais entry-level comprimé | Moyen | +$37B marché 2024→2029 mais –45% entry jobs | $61B 2029 market, hiring reprend Q2 2026 | Talent pipeline fragile, urgence reskill juniors |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Agents de Code : Quoi de neuf
|
||||||
|
|
||||||
|
### 1. OpenAI Codex GPT-5.5 : Agentic Complet = #1 Ranking Mai 2026
|
||||||
|
|
||||||
|
**Status :** Production GA
|
||||||
|
**Quoi :** GPT-5.5 Codex dans le top #1 ranking pour agents code en mai 2026 (dépassant Claude Code pour la première fois).
|
||||||
|
|
||||||
|
**Capacités clés :**
|
||||||
|
- Multi-file editing (traverse codebase complet)
|
||||||
|
- Git orchestration natif (commits, PR, branches)
|
||||||
|
- Test automation + linting (cycle TDD autonome)
|
||||||
|
- Prompt templates + model settings (prompt versioning)
|
||||||
|
- 30–50% temps coding réduit vs approach manuel
|
||||||
|
- 25% plus rapide que GPT-5.3-Codex précédent
|
||||||
|
|
||||||
|
**Impact sur devs :**
|
||||||
|
- Seniors peuvent déléguer 50–70% routine coding → focus architecture
|
||||||
|
- Juniors : tâches routine disparaissent, doivent apprendre orchestration + code review d'agents
|
||||||
|
- Équipes : capacité delivery +X, friction onboarding juniors augmente (moins de mentor time)
|
||||||
|
|
||||||
|
**Pour vos équipes :**
|
||||||
|
- Devs doivent apprendre "prompt engineering for agents" (template design)
|
||||||
|
- New skill : agent output validation, not code writing
|
||||||
|
- Juniors risk : upskilled rapidement ou obsolescence
|
||||||
|
|
||||||
|
**Sources :**
|
||||||
|
- [Best AI Coding Agents in 2026, Ranked — MightyBot](https://mightybot.ai/blog/coding-ai-agents-for-accelerating-engineering-workflows/)
|
||||||
|
- [ChatGPT Codex Guide 2026: AI Coding Agent Explained](https://two99.org/blog/chatgpt-codex-guide-2026/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2. Anthropic Claude Managed Agents : "Dreaming" + Orchestration Multi-Agent
|
||||||
|
|
||||||
|
**Status :** Research preview (dreaming), public beta (orchestration)
|
||||||
|
**Quoi :** Anthropic ajoute "dreaming" (agent review past sessions pour self-improvement) + multiagent orchestration + webhooks.
|
||||||
|
|
||||||
|
**Capacités clés :**
|
||||||
|
- **Dreaming** : agents examine historique pour pattern finding, self-improve sans human
|
||||||
|
- **Multiagent orchestration** : coordonner multiple agents sur tâches complexes
|
||||||
|
- **Webhooks** : agents trigger external systems (Slack, JIRA, GitHub)
|
||||||
|
- **17x API growth YoY** = devs vote with feet
|
||||||
|
|
||||||
|
**Impact sur devs :**
|
||||||
|
- Agents plus autonomes = less human steering = teams smaller
|
||||||
|
- Juniors : rôle shift from coding to monitoring + incident response
|
||||||
|
- Seniors : architecting multi-agent systems devient core skill
|
||||||
|
|
||||||
|
**Pour vos équipes :**
|
||||||
|
- Claude Managed Agents = AWS Lambda but for agents (serverless reasoning)
|
||||||
|
- Cost control critique (dreaming = extra compute)
|
||||||
|
- Multi-agent patterns = learning curve, mais puissant
|
||||||
|
|
||||||
|
**Sources :**
|
||||||
|
- [2026 Agentic Coding Trends Report](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf)
|
||||||
|
- [Anthropic updates Claude Managed Agents with three new features - 9to5Mac](https://9to5mac.com/2026/05/07/anthropic-updates-claude-managed-agents-with-three-new-features/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 3. GitHub Copilot : Mainstream Adoption = 4.7M Payants (Janvier 2026)
|
||||||
|
|
||||||
|
**Status :** Enterprise standard
|
||||||
|
**Quoi :** GitHub Copilot atteint 4.7M utilisateurs payants, +75% YoY (janvier 2026).
|
||||||
|
|
||||||
|
**Impact metrics :**
|
||||||
|
- **51% faster coding** (developer self-report)
|
||||||
|
- **88% suggestion retention** (high quality)
|
||||||
|
- **3.6 hours/week saved** per dev = $967/month value at $130K US salary
|
||||||
|
- **55% task completion faster** (GitHub study)
|
||||||
|
- Deployed dans ~90% Fortune 100 = enterprise standard
|
||||||
|
|
||||||
|
**ROI Calc :**
|
||||||
|
- 50-dev team : $11.4K–$23.4K annual (Copilot cost) = 1–2% of compensation = breakeven Q1
|
||||||
|
- Most orgs see positive ROI within first quarter at 10–11% productivity gain
|
||||||
|
|
||||||
|
**Impact sur devs :**
|
||||||
|
- Seniors : validation overhead (–19% productivity some seniors), mieux sur architecture
|
||||||
|
- Juniors : +10–30% boost, mais skill development risk (less struggle = less depth learning)
|
||||||
|
- Teams : hiring bar rises, code review focus shifts (less typo hunting, more logic review)
|
||||||
|
|
||||||
|
**Adoption signal :**
|
||||||
|
- 51% faster vs human baseline is substantial, not marginal
|
||||||
|
- 4.7M users = **Copilot is now table stakes for dev tools**, not optional
|
||||||
|
|
||||||
|
**Sources :**
|
||||||
|
- [GitHub Copilot Statistics 2026 — Users, Revenue & Adoption](https://www.getpanto.ai/blog/github-copilot-statistics)
|
||||||
|
- [GitHub Copilot Statistics & Adoption Trends [2026]](https://www.secondtalent.com/resources/github-copilot-statistics/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4. Microsoft Copilot Studio : Subagents Visual Studio + Low-Code Agent Building
|
||||||
|
|
||||||
|
**Status :** Public preview (subagents VS), GA (Copilot Studio)
|
||||||
|
**Quoi :** Microsoft ajoute subagents capability VS Code + low-code agent building for non-programmers.
|
||||||
|
|
||||||
|
**Capacités clés :**
|
||||||
|
- **Subagents in VS Code** : agents parallels, context isolation, custom agents
|
||||||
|
- **Copilot Studio extension** : build/edit/manage agents in IDE (no cloud IDE hop)
|
||||||
|
- **Low-code agent design** : business analysts build agents, not devs only
|
||||||
|
- **Multi-agent orchestration** (GA May 2026) : Fabric + M365 agents SDK + open A2A protocol
|
||||||
|
|
||||||
|
**Impact sur teams :**
|
||||||
|
- Developer role splits : senior devs = architecture, junior devs can supervise agents
|
||||||
|
- Non-programmer roles : finance planners, customer service managers build agents (1–1.5h saved/day)
|
||||||
|
- Enterprise tool leverage : Dynamics 365 + agents = workflow automation scale
|
||||||
|
- Governance question : agents built outside dev teams = risk
|
||||||
|
|
||||||
|
**For your teams :**
|
||||||
|
- Microsoft = enterprise play, Anthropic/OpenAI = dev-first
|
||||||
|
- Copilot Studio good for business user agents, not complex logic
|
||||||
|
- Subagents = parallelism, but coordination complexity rises
|
||||||
|
|
||||||
|
**Sources :**
|
||||||
|
- [What's new in Copilot Studio: Multi-agent systems](https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/new-and-improved-multi-agent-orchestration-connected-experiences-and-faster-prompt-iteration/)
|
||||||
|
- [AI Subagents 'Coming Soon' to Visual Studio Copilot](https://visualstudiomagazine.com/articles/2026/05/06/ai-subagents-coming-to-visual-studio-ides-copilot.aspx)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Marché Emploi Devs : Les Vraies Données
|
||||||
|
|
||||||
|
### 1. Marché Logiciels Explose : +20% Annuel
|
||||||
|
|
||||||
|
**Market Size :**
|
||||||
|
- **2024** : $24 billion
|
||||||
|
- **2029** : $61 billion (projected)
|
||||||
|
- **CAGR** : +20% annuel
|
||||||
|
|
||||||
|
**Implication :** Malgré transformation AI, demand logiciel croît **plus vite** que AI adoption. Jobs not vanishing, but reshaping.
|
||||||
|
|
||||||
|
**Reality check :** Si marché +20%/an mais agents +30–50% productivity, demand talent flatte ou baisse légèrement en headcount. Mais **mix change** : moins juniors, plus seniors architecting + agent orchestration.
|
||||||
|
|
||||||
|
### 2. Salaires AI-Savvy Devs : $90K–$130K Entry-Level
|
||||||
|
|
||||||
|
**Salary premium :**
|
||||||
|
- **Traditional entry-level dev** : $65K–$85K
|
||||||
|
- **AI-savvy dev (generalist)** : $90K–$130K
|
||||||
|
- **Differential** : +$25K–$45K for AI knowledge
|
||||||
|
|
||||||
|
**Context :**
|
||||||
|
- GitHub Copilot users average : $95.3K (February 2026)
|
||||||
|
- Senior+ roles : architecture + AI orchestration pull $130K+
|
||||||
|
|
||||||
|
**Implication :** AI skills matter immediately in hiring. Juniors without AI exposure fall to $65K band; AI-aware juniors $90K+. **Reskill or slide down salary ladder.**
|
||||||
|
|
||||||
|
### 3. Entry-Level Hiring : Recovery but Still Down
|
||||||
|
|
||||||
|
**Data :**
|
||||||
|
- **Entry-level postings** : –45% vs 2023 peak
|
||||||
|
- **Overall dev postings** : +15% since mid-2025 (recovery starting)
|
||||||
|
- **Hiring pattern** : precision hiring (revenue-driving roles only), not broad entry-level pipeline
|
||||||
|
|
||||||
|
**Implication :**
|
||||||
|
1. Juniors hardest hit : routine coding jobs disappearing before they onboard
|
||||||
|
2. Training programs rare (companies hire "ready now")
|
||||||
|
3. Bootcamp grads struggling (less entry jobs, more competition)
|
||||||
|
4. Possible bifurcation : strong juniors ($90K+) vs unemployed juniors (no role fit)
|
||||||
|
|
||||||
|
**Opportunity :** Companies that invest reskilling existing juniors gain huge talent advantage.
|
||||||
|
|
||||||
|
### 4. Skill Shift : What's In, What's Out
|
||||||
|
|
||||||
|
**In-demand 2026 :**
|
||||||
|
- **AI/GenAI** (obvious)
|
||||||
|
- **Systems design** + **architecture** (seniors must do this)
|
||||||
|
- **Cloud architecture** (AWS/GCP/Azure patterns)
|
||||||
|
- **Cybersecurity** + **secure coding**
|
||||||
|
- **Data engineering** (feature stores, data quality)
|
||||||
|
- **Agent orchestration** (new, specific)
|
||||||
|
- **DevOps/SRE** (monitoring agents != monitoring monoliths)
|
||||||
|
- **Low-code/no-code** (automation platforms)
|
||||||
|
|
||||||
|
**Out-of-demand / Declining :**
|
||||||
|
- **Boilerplate coding** (agents handle)
|
||||||
|
- **Routine code review** (automated)
|
||||||
|
- **Frontend pixel-perfect** (Figma → code agents)
|
||||||
|
- **Junior "grind" work** (delegation to AI)
|
||||||
|
|
||||||
|
**Languages still hot :** TypeScript, Python, Rust (systems), Go (infra)
|
||||||
|
|
||||||
|
**Real implication :** Devs under 35 with only "write CRUD APIs" skills obsolete by 2027. Must level up to architecture, system design, or adjacent skills (product, AI training).
|
||||||
|
|
||||||
|
### 5. Team Composition Inversion
|
||||||
|
|
||||||
|
**Old model (2024) :**
|
||||||
|
- 60% juniors, 30% mid-level, 10% seniors
|
||||||
|
- Juniors = cheap labor, mentored slowly
|
||||||
|
- Seniors = architects + problem solvers
|
||||||
|
|
||||||
|
**New model emerging (2026+) :**
|
||||||
|
- 20% juniors (or zero), 40% mid-level + seniors, 40% agents
|
||||||
|
- Remaining juniors = high-performer fast-trackers only
|
||||||
|
- Seniors = AI oversight + system design
|
||||||
|
- Agents = routine execution (PR generation, test writing, deployment automation)
|
||||||
|
|
||||||
|
**For team leaders :**
|
||||||
|
- Hiring juniors risky (less mentoring ROI, agents do their work)
|
||||||
|
- Investing in senior leadership + architecture critical
|
||||||
|
- Onboarding non-AI juniors = liability
|
||||||
|
|
||||||
|
**Sources :**
|
||||||
|
- [Developer Job Market Recovery 2026: Data Analysis and Trends](https://pooya.blog/blog/software-dev-job-market-recovery-2026/)
|
||||||
|
- [The demise of software engineering jobs has been greatly exaggerated | CNN Business](https://www.cnn.com/2026/04/08/tech/ai-software-developer-jobs)
|
||||||
|
- [Tech Job Market 2026: Trends, Skills, and Opportunities](https://legacy.anitab.org/blog/resources/tech-job-market-2026/)
|
||||||
|
- [AI Impact on the Job Market in 2026: What the Data Shows](https://www.secondtalent.com/resources/ai-impact-job-market-2026/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Impact sur Chefs de Projets & Product Managers
|
||||||
|
|
||||||
|
### 1. Delivery Acceleration : Weeks → Days
|
||||||
|
|
||||||
|
**Data :**
|
||||||
|
- Development time for complex features : **–70% timeline** (some reports)
|
||||||
|
- Tasks that required weeks of cross-team coordination : **focused working sessions now**
|
||||||
|
- Agents handle dependency resolution, multi-file changes, testing
|
||||||
|
|
||||||
|
**Impact on PMs :**
|
||||||
|
- Feature velocity up sharply
|
||||||
|
- Scope creep risk UP (if roadmap doesn't tighten)
|
||||||
|
- Estimation harder (agents variable quality)
|
||||||
|
- Release frequency can spike
|
||||||
|
|
||||||
|
### 2. Quality Variance : Agents Good at Routine, Risky on Novel
|
||||||
|
|
||||||
|
**Data from Anthropic 2026 Agentic Coding Trends :**
|
||||||
|
- Agents excel : bug fixes, boilerplate, test generation, refactoring
|
||||||
|
- Agents struggle : novel architecture, security-critical logic, cross-domain reasoning
|
||||||
|
|
||||||
|
**Impact on PMs :**
|
||||||
|
- Code review process ≠ old process (shift to logic validation, not syntax)
|
||||||
|
- Testing strategy must evolve (agent-generated code needs different test lenses)
|
||||||
|
- Risk : shipping lower-quality agents output without proper gates
|
||||||
|
|
||||||
|
### 3. Team Dynamics : Autonomy but Coordination Risk
|
||||||
|
|
||||||
|
**Data :** 81% of leaders report agents shifting team work to strategic + relationship-building.
|
||||||
|
|
||||||
|
**But risk :** With less manual coding, sync points blur. Multiple agents running = orchestration complexity.
|
||||||
|
|
||||||
|
**Impact on PMs :**
|
||||||
|
- More stand-ups to coordinate agents (ironic)
|
||||||
|
- Slack becomes incident response channel (agent failures)
|
||||||
|
- Tooling for agent observability / logging = new overhead
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Opportunités Concrètes pour Équipes
|
||||||
|
|
||||||
|
### Immédiat (2–4 semaines)
|
||||||
|
|
||||||
|
| Action | Effort | Impact | Priorité |
|
||||||
|
|---|---:|---|---|
|
||||||
|
| Évaluer GitHub Copilot pilot (5 devs) | Faible | Mesurer +% productivité réelle vs hype | ⭐⭐⭐ |
|
||||||
|
| Reskill plan : seniors → agent architecture | Moyen | Prevent talent outflow, clarify role evolution | ⭐⭐⭐ |
|
||||||
|
| Audit junior pipeline : AI-skill entry bar | Faible | Understand talent market, adjust hiring | ⭐⭐⭐ |
|
||||||
|
| Test GPT-5.5 Codex vs Anthropic Claude agents | Faible | Pick best for your stack (OpenAI = fast, Anthropic = safe) | ⭐⭐ |
|
||||||
|
|
||||||
|
### Q2 2026 (Next 2 months)
|
||||||
|
|
||||||
|
| Action | Effort | Impact | Priorité |
|
||||||
|
|---|---:|---|---|
|
||||||
|
| Deploy Copilot @ scale (team of 15+) | Moyen | Measure real ROI, training, code review impact | ⭐⭐⭐ |
|
||||||
|
| Build agent orchestration workflow (Gestéos?) | Moyen | Test multiagent patterns, learn multi-step coordination | ⭐⭐⭐ |
|
||||||
|
| Create "agent operator" role definition | Faible | Clarity hiring + upskilling path | ⭐⭐ |
|
||||||
|
| Establish agent code review gates | Moyen | Quality + security (agents can hallucinate security bugs) | ⭐⭐ |
|
||||||
|
|
||||||
|
### Strategic (H2 2026)
|
||||||
|
|
||||||
|
| Action | Effort | Impact | Priorité |
|
||||||
|
|---|---:|---|---|
|
||||||
|
| Rethink team structure (fewer juniors, more seniors?) | Fort | Revenue-driving but cultural change | ⭐⭐ |
|
||||||
|
| Build custom agents for Seenaps / Gestéos | Fort | Product differentiation (agents as feature) | ⭐⭐ |
|
||||||
|
| Invest in senior talent (architecture, security) | Fort | Counter talent outflow, build moat vs competitor automation | ⭐⭐ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points de Vigilance
|
||||||
|
|
||||||
|
| Risque | Données | Mitigation |
|
||||||
|
|---|---|---|
|
||||||
|
| **Junior talent drought** | Entry-level –45% vs 2023, training programs rare | Upskill existing juniors aggressively, compete on senior roles |
|
||||||
|
| **Salary compression** | AI-savvy $90K–$130K vs traditional $65K–$85K, but fewer entry jobs | Risk bifurcation (haves = AI-aware, have-nots = unemployable) |
|
||||||
|
| **Code quality blind spots** | Agents excel routine, fail novel logic + security | Stricter code review gates, agent output audits mandatory |
|
||||||
|
| **Estimation whiplash** | Agent productivity variable (task type, model, prompt quality) | Build buffers, measure velocity per agent type over time |
|
||||||
|
| **Orchestration chaos** | Multi-agent systems hard to debug, coordinate | Invest in observability (agent logging, state tracing) early |
|
||||||
|
| **Dependency lock-in** | OpenAI (GPT-5.5) vs Anthropic (Claude Opus) vs Microsoft (Copilot) = vendor lock-in on model choice | Multi-model testing strategy, avoid single vendor |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Questions pour vos Équipes
|
||||||
|
|
||||||
|
1. **Hiring :** How do you recruit juniors in an AI agents world? Bootcamp grads won't get roles. Build internal pipeline?
|
||||||
|
2. **Skills :** What does "senior engineer" mean in 2027? Code architect? Agent orchestration expert? Product strategist?
|
||||||
|
3. **Quality :** How do you validate agent-generated code? Humans can't code-review faster than agents generate.
|
||||||
|
4. **Cost :** GitHub Copilot = $10/mo. Claude API agents? OpenAI Codex? Token costs explode at scale.
|
||||||
|
5. **Responsibility :** If agent ships a bug, who owns it? Developer? PM? Agent trainer?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## À Intégrer dans PKM
|
||||||
|
|
||||||
|
| Note | Action | Contexte |
|
||||||
|
|---|---|---|
|
||||||
|
| 20-areas/pro/management/hiring-strategy-2026 | Créer : framework for AI-era hiring (junior pipeline) | Urgence : talent market shifting Q2 2026 |
|
||||||
|
| 20-areas/pro/cto/tech-stack-agents | Créer : decision matrix (OpenAI vs Anthropic vs Microsoft) + cost modeling | OKR O1-KR1 |
|
||||||
|
| 20-areas/pro/seenaps/team-structure-v2 | Créer : rethink Seenaps team roles for agent-augmented delivery | Product differentiation + delivery speed |
|
||||||
|
| 30-resources/tech/ia/agent-orchestration-patterns | Créer : playbook for multiagent systems (Copilot + Claude + custom) | Knowledge base, train team |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Bibliographie Veille
|
||||||
|
|
||||||
|
| Source | Éditeur | Date | Focus |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| [2026 Agentic Coding Trends Report](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf) | Anthropic | May 2026 | Impact agents sur dev, marché, skills |
|
||||||
|
| [Agentic Coding in 2026: AI's Impact on Software Development](https://www.timesofai.com/industry-insights/agentic-coding-in-software-development/) | Times of AI | 2026 | Trends macro, productivity debate |
|
||||||
|
| [The demise of software engineering jobs has been greatly exaggerated](https://www.cnn.com/2026/04/08/tech/ai-software-developer-jobs) | CNN Business | April 2026 | Job market reality check |
|
||||||
|
| [Best AI Coding Agents in 2026: Real-World Developer Reviews](https://www.faros.ai/blog/best-ai-coding-agents-2026) | Faros AI | 2026 | Tool comparison + benchmarks |
|
||||||
|
| [State of Code Developer Survey report 2026](https://www.sonarsource.com/state-of-code-developer-survey-report.pdf) | SonarSource | 2026 | Developer sentiment, adoption rates |
|
||||||
|
| [Developer Job Market Recovery 2026: Data Analysis and Trends](https://pooya.blog/blog/software-dev-job-market-recovery-2026/) | Pooya Golchian | 2026 | Jobs + hiring patterns |
|
||||||
|
| [GitHub Copilot Statistics 2026](https://www.getpanto.ai/blog/github-copilot-statistics) | GetPanto | 2026 | Adoption, metrics, ROI |
|
||||||
|
| [How enterprises are building AI agents in 2026](https://claude.com/blog/how-enterprises-are-building-ai-agents-in-2026) | Anthropic Blog | 2026 | Enterprise patterns |
|
||||||
|
| [AI Impact on the Job Market in 2026: What the Data Shows](https://www.secondtalent.com/resources/ai-impact-job-market-2026/) | Second Talent | 2026 | Labor market shifts |
|
||||||
282
80-sources/tech-ia/2026-05-10-veille-tech-ia.md
Normal file
282
80-sources/tech-ia/2026-05-10-veille-tech-ia.md
Normal file
|
|
@ -0,0 +1,282 @@
|
||||||
|
# Veille Tech & IA - 2026-05-10
|
||||||
|
|
||||||
|
## Synthèse exécutive
|
||||||
|
|
||||||
|
MLOps arrive à maturité avec MLflow 3.12 (prompt models, trace observability) et outils cloud unifiés. **Agentic RAG s'impose comme architecture par défaut** pour production : combine itération multi-steps + RAG, dépassant vanilla RAG sur benchmark. Claude Opus 4.7 GA avec code improvements + Claude Security beta. Ces trois signaux alimentent directement O1-KR2 (PAI dev) et O1-KR1 (équipe IA). Infrastructure monitoring MLOps devient critique : 4 layers (infra/data/model/business KPIs).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Top 5 des signaux forts
|
||||||
|
|
||||||
|
| Sujet | Importance | OKR Q2 impacté | Pourquoi c'est important | Impact potentiel | Action recommandée |
|
||||||
|
|---|---:|---|---|---|---|
|
||||||
|
| MLflow 3.12.0 + prompt models | Fort | O1-KR2 | Model registry + prompt versioning = socle PAI | Réduit friction versioning modèles IA | Tester intégration MLflow sur Factory |
|
||||||
|
| Agentic RAG devient standard 2026 | Fort | O1-KR1, O1-KR3 | Outperform vanilla RAG, production-ready pour support | Support assisté gagne en précision | Évaluer LangGraph vs LlamaIndex pour Gestéos |
|
||||||
|
| Claude Opus 4.7 GA + Claude Security | Moyen | O1-KR1 | Code improvements + security scanning beta | Améliore capacités agents dev, sécurité | Tester Opus 4.7 sur agents Seenaps |
|
||||||
|
| MLOps monitoring 4-layers | Moyen | O2-KR2 | Infra + data quality + model perf + business KPIs | Pilotage PAI lisible | Implémenter observabilité Arize ou équiv |
|
||||||
|
| Cloud platforms unified MLOps | Moyen | O1-KR2, O2-KR2 | SageMaker + Vertex AI + Databricks convergent | Moins de friction cloud choice | Décider stack cloud pour PAI |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Alignement OKR Q2
|
||||||
|
|
||||||
|
| OKR | Signal | Recommandation |
|
||||||
|
|---|---|---|
|
||||||
|
| O1-KR1 (Équipe IA-augmentée) | Agentic RAG, Claude Opus 4.7, LangGraph GA | Lancer workshop agents patterns (LangGraph) |
|
||||||
|
| O1-KR2 (PAI dev) | MLflow 3.12, monitoring 4-layers, cloud convergence | Planifier architecture PAI avec MLflow + monitoring |
|
||||||
|
| O1-KR3 (Support assisté) | Agentic RAG use case support, Claude Security | Pilot agentic RAG sur Gestéos support |
|
||||||
|
| O2-KR2 (Bases techniques) | MLOps architecture practices, feature stores | Documenter feature store strategy |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## IA générative & agents
|
||||||
|
|
||||||
|
### Agentic RAG : le pattern de production 2026
|
||||||
|
|
||||||
|
**Importance :** Fort
|
||||||
|
**Résumé :**
|
||||||
|
Agentic RAG (agents IA autonomes + RAG itératif) devient l'architecture par défaut pour Q&A complexes. Différence clé : boucle de raisonnement multi-steps vs pipeline linéaire vanilla RAG. Frameworks : LangGraph, LlamaIndex Agents, AutoGen, CrewAI. Résultats : outperform vanilla RAG sur accuracy benchmarks, déploiements customer support/legal research/finance.
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
Directement applicable à O1-KR1 (équipe IA patterns) et O1-KR3 (support assisté). Pattern permet support + agents complexes sans hacks.
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Support Gestéos passe de RAG basique à agent autonome capable de naviguer plusieurs données sources et réitérer. Agents Seenaps gagnent en robustesse.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Lancer workshop sur agentic RAG pattern (2h), vérifier compatibilité Claude avec LangGraph, piloter Gestéos.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [What is Agentic RAG? Everything You Need to Know in 2026](https://www.lyzr.ai/blog/agentic-rag/)
|
||||||
|
- [Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG](https://arxiv.org/abs/2501.09136)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Claude Opus 4.7 GA + Claude Security beta
|
||||||
|
|
||||||
|
**Importance :** Moyen
|
||||||
|
**Résumé :**
|
||||||
|
Claude Opus 4.7 disponible en GA : meilleur perf code/vision. Claude Security en public beta pour Enterprise : code vulnerability scanning, proposed fixes, scheduled scans, triage tracking. Design tool et interactive apps (iOS/Android).
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
Améliore capacités agents dev (code gen + audit). Security scanning utile pour agents Seenaps qui génèrent code.
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Agents Seenaps gagnent +X% accuracy code generation. Code review plus automatisée.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Tester Opus 4.7 sur agents Seenaps. Évaluer Claude Security pour pipeline dev.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [Claude Updates by Anthropic - May 2026 - Releasebot](https://releasebot.io/updates/anthropic/claude)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Développement logiciel & outils développeurs
|
||||||
|
|
||||||
|
### LangChain + LlamaIndex : native structured output & token counting updates
|
||||||
|
|
||||||
|
**Importance :** Moyen
|
||||||
|
**Résumé :**
|
||||||
|
LangChain supporte structured output natif Anthropic (garantit adhérence à schema). LlamaIndex met à jour token counting API (older models deprecated). Anthropic intégration robuste.
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
Structured output = moins de parsing, moins d'erreurs en production. Token counting critique pour cost control O1-KR2 (PAI).
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Agents Seenaps gagnent en fiabilité output. Cost tracking plus précis.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Migrer agents Seenaps vers structured output LangChain. Auditer token counting dans Factory.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [Docs by LangChain - ChatAnthropic integration](https://docs.langchain.com/oss/python/integrations/chat/anthropic)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Produit, spécifications & organisation
|
||||||
|
|
||||||
|
*Aucun signal prioritaire cette semaine.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sécurité, RGPD & gouvernance IA
|
||||||
|
|
||||||
|
### Claude Security : code vulnerability scanning en public beta
|
||||||
|
|
||||||
|
**Importance :** Moyen
|
||||||
|
**Résumé :**
|
||||||
|
Claude Security (Anthropic Labs) : scan automatisé vulnérabilités code, proposed fixes, scheduled/targeted scans, export/integrations workflow.
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
Agents devs Seenaps qui genèrent code doivent checker sécurité. Gouvernance IA requiert audit.
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Réduction risque code injection / vulnérabilités agents. Compliance audit facilité.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Évaluer Claude Security pour pipeline Seenaps. Documenter dans governance IA.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [Claude Updates by Anthropic - May 2026 - Releasebot](https://releasebot.io/updates/anthropic/claude)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Architecture, data & cloud
|
||||||
|
|
||||||
|
### MLflow 3.12.0 : prompt model configuration + trace observability
|
||||||
|
|
||||||
|
**Importance :** Fort
|
||||||
|
**Résumé :**
|
||||||
|
MLflow 3.12 : prompt model configuration (model settings + prompt templates), in-progress trace display + auto-polling, DeepEval + RAGAS judges (20+ evaluation metrics). 30M monthly downloads, de facto open core pour AI stacks.
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
**Direct O1-KR2 (PAI dev).** MLflow = socle version control + evaluation pour Factory. Nouvelles features (trace, evaluation) = observabilité production.
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Factory PAI : versioning models + prompts, evaluation en continu, debugging production facilitée.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Implémenter MLflow 3.12 sur Factory. Tester prompt versioning. Intégrer judges evaluation.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [MLflow - Open Source AI Platform for Agents, LLMs & Models](https://mlflow.org/)
|
||||||
|
- [MLflow 3.12.0](https://mlflow.org/releases/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### MLOps 2026 : monitoring 4-layers + infrastructure automation
|
||||||
|
|
||||||
|
**Importance :** Fort
|
||||||
|
**Résumé :**
|
||||||
|
MLOps mature en 2026 : monitoring 4 layers = infrastructure (latency/errors) + data quality (drift/anomalies) + model perf (accuracy/confidence) + business impact (KPIs). Infrastructure automation : dynamic resource allocation. Observability intègre business metrics.
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
**O2-KR2 (bases techniques).** PAI impossible à piloter sans observabilité correcte. 4 layers = lisibilité production.
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Factory PAI : monitoring < 5 min setup. Alertes connectées à business. Debugging modèles IA accéléré.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Documenter observabilité PAI : 4 layers. Tester Arize ou Datadog ML monitoring. Automatiser alertes business.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [MLOps in 2026: Architecture, Trends & Strategy Guide](https://hyscaler.com/insights/mlops-in-2026-guide/)
|
||||||
|
- [The Complete MLOps/LLMOps Roadmap for 2026: Building Production-Grade AI Systems](https://medium.com/@sanjeebmeister/the-complete-mlops-llmops-roadmap-for-2026-building-production-grade-ai-systems-bdcca5ed2771)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Cloud platforms convergence : SageMaker + Vertex AI + Databricks
|
||||||
|
|
||||||
|
**Importance :** Moyen
|
||||||
|
**Résumé :**
|
||||||
|
SageMaker, Vertex AI, Databricks convergent sur MLOps unified : open core (MLflow, BentoML) + managed services. "Managed Open Core" pattern : standards ouverts + cloud propriétaire.
|
||||||
|
|
||||||
|
**Pourquoi c'est important :**
|
||||||
|
O1-KR2 + O2-KR2. Cloud choice impacte PAI design. Pattern émergent = flexibilité.
|
||||||
|
|
||||||
|
**Impact potentiel :**
|
||||||
|
Factory : pas de lock-in cloud. MLflow portable. Coût + performance optimisé par cloud.
|
||||||
|
|
||||||
|
**Action recommandée :**
|
||||||
|
Décider : SageMaker vs Vertex AI vs Databricks pour PAI. Valider portabilité MLflow.
|
||||||
|
|
||||||
|
**Source :**
|
||||||
|
- [Best MLOps platforms in 2026 - Addepto](https://addepto.com/mlops-platforms-in-2026/)
|
||||||
|
- [26 MLOps Tools for 2026: Key Features & Benefits](https://lakefs.io/mlops/mlops-tools/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Opportunités concrètes pour nous
|
||||||
|
|
||||||
|
| Opportunité | Bénéfice attendu | Effort estimé | Priorité |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| Implémenter MLflow 3.12 sur Factory | Versioning + evaluation production-grade | Moyen | ⭐⭐⭐ |
|
||||||
|
| Lancer workshop agentic RAG (patterns) | Équipe alignée sur architecture agents | Faible | ⭐⭐⭐ |
|
||||||
|
| Tester Opus 4.7 + structured output | Code quality agents +X%, moins de parsing | Faible | ⭐⭐⭐ |
|
||||||
|
| Implémenter 4-layer monitoring | Observabilité Production PAI opérationelle | Fort | ⭐⭐ |
|
||||||
|
| Évaluer Claude Security pour agents dev | Code quality + compliance | Faible | ⭐⭐ |
|
||||||
|
| Décider stack cloud PAI (Saga/Vertex/DB) | Pas de lock-in, portabilité | Moyen | ⭐⭐ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Idées à tester
|
||||||
|
|
||||||
|
### Expérimentation rapide, moins d'une journée
|
||||||
|
|
||||||
|
- Tester `structured_output` LangChain + Claude Opus 4.7 sur agent prototype
|
||||||
|
- Scanner token usage agent existant avec updated token counting API
|
||||||
|
- Créer minimal prompt versioning example avec MLflow 3.12
|
||||||
|
|
||||||
|
### Expérimentation d'équipe
|
||||||
|
|
||||||
|
- Workshop 2h agentic RAG : LangGraph vs LlamaIndex, patterns, quand utiliser
|
||||||
|
- Tester MLflow 3.12 intégration sur Factory (model registry + prompts)
|
||||||
|
- Setup trace observability MLflow sur 1 agent Seenaps pilot
|
||||||
|
|
||||||
|
### Expérimentation produit ou client
|
||||||
|
|
||||||
|
- Pilot agentic RAG sur Gestéos support (vs vanilla RAG baseline)
|
||||||
|
- Évaluer Claude Security scanning sur Seenaps code gen agents
|
||||||
|
|
||||||
|
### Expérimentation PKM / documentation / spécifications
|
||||||
|
|
||||||
|
- Documenter decision matrix : cloud platform selection (SageMaker vs Vertex vs Databricks)
|
||||||
|
- Spécifier 4-layer monitoring architecture pour PAI
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points de vigilance
|
||||||
|
|
||||||
|
| Risque | Pourquoi c'est un risque | Action préventive |
|
||||||
|
|---|---|---|
|
||||||
|
| Agentic RAG complexité vs vanilla RAG | Coût compute + latency agent loops | Benchmarker vs baseline vanilla sur Gestéos |
|
||||||
|
| Cloud lock-in pattern "Managed Open Core" | Proprietary services coutent cher, migration future difficile | Valider portabilité MLflow avant sélection cloud |
|
||||||
|
| Claude Security beta instability | Nouvelles features = bugs potentiels | Pilot sur non-prod d'abord, monitorer alertes faux positifs |
|
||||||
|
| Token counting deprecation older models | Agent legacy cassent si models deprecated | Migrer agents vers Claude-3.5+ avant deadline |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## À intégrer dans mon PKM
|
||||||
|
|
||||||
|
| Note PKM | Action | Pourquoi |
|
||||||
|
|---|---|---|
|
||||||
|
| 10-projects/ameno (Factory PAI) | Enrichir avec MLflow 3.12 + monitoring 4-layers | O1-KR2 feedback |
|
||||||
|
| 20-areas/pro/seenaps/tech | Créer decision matrix cloud platforms | O1-KR2 + O2-KR2 planning |
|
||||||
|
| 30-resources/tech/architecture | Documenter agentic RAG pattern, LangGraph | O1-KR1 équipe reference |
|
||||||
|
| 30-resources/tech/ia | Créer checklist agents governance (Claude Security) | Compliance + security |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Questions à creuser
|
||||||
|
|
||||||
|
1. LangGraph vs LlamaIndex Agents : tradeoffs pour Seenaps agents ?
|
||||||
|
2. MLflow 3.12 token counting : comment integrer dans Factory cost tracking ?
|
||||||
|
3. Agentic RAG latency : acceptable pour Gestéos support real-time ?
|
||||||
|
4. Claude Security : available en API ou desktop client seulement ?
|
||||||
|
5. 4-layer monitoring : Arize vs Datadog vs custom pour budget startup ?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sources consultées
|
||||||
|
|
||||||
|
| Source | Éditeur | Date | Lien |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| MLflow 3.12.0 Release | MLflow | 2026-05 | [MLflow Releases](https://mlflow.org/releases/) |
|
||||||
|
| Agentic RAG 2026 | Lyzr | 2026-05 | [What is Agentic RAG?](https://www.lyzr.ai/blog/agentic-rag/) |
|
||||||
|
| Claude Updates May 2026 | Anthropic | 2026-05 | [Claude Updates - Releasebot](https://releasebot.io/updates/anthropic/claude) |
|
||||||
|
| MLOps 2026 Guide | Hyscaler | 2026-05 | [MLOps in 2026: Architecture, Trends & Strategy](https://hyscaler.com/insights/mlops-in-2026-guide/) |
|
||||||
|
| MLOps Roadmap 2026 | Medium (Sanjeeb) | 2026-05 | [Complete MLOps/LLMOps Roadmap 2026](https://medium.com/@sanjeebmeister/the-complete-mlops-llmops-roadmap-for-2026-building-production-grade-ai-systems-bdcca5ed2771) |
|
||||||
|
| MLflow Alternatives Review | ZenML | 2026 | [ZenML Blog - MLflow Alternatives](https://www.zenml.io/blog/mlflow-alternatives) |
|
||||||
|
| LangChain Anthropic Integration | LangChain | 2026 | [LangChain Docs - Anthropic](https://docs.langchain.com/oss/python/integrations/chat/anthropic) |
|
||||||
|
| Agentic RAG Survey | arXiv | 2025-01 | [Agentic RAG Survey](https://arxiv.org/abs/2501.09136) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Actions recommandées pour la semaine prochaine
|
||||||
|
|
||||||
|
- [ ] Lancer workshop agentic RAG : patterns, LangGraph demo (2h, équipe Seenaps)
|
||||||
|
- [ ] Tester MLflow 3.12 sur Factory : setup model registry + prompt versioning (4h, dev Factory)
|
||||||
|
- [ ] Évaluer Opus 4.7 structured output sur agent pilot (2h, dev agents)
|
||||||
|
- [ ] Créer decision matrix : SageMaker vs Vertex vs Databricks (2h, CTO + lead tech)
|
||||||
|
- [ ] Documenter 4-layer monitoring spec pour PAI (3h, observabilité lead)
|
||||||
234
99-templates/note-veille-emploi-devs.md
Normal file
234
99-templates/note-veille-emploi-devs.md
Normal file
|
|
@ -0,0 +1,234 @@
|
||||||
|
# Veille Emploi & Devs - YYYY-MM-01
|
||||||
|
|
||||||
|
## Synthèse exécutive
|
||||||
|
|
||||||
|
Résumer en 8–12 lignes :
|
||||||
|
- État du marché emploi dev (hiring ↑/↓, trend salaires)
|
||||||
|
- Impact AI agents sur rôles devs (juniors vs seniors, skills shift)
|
||||||
|
- Implication directe pour hiring strategy et team structure
|
||||||
|
- 1–2 red flags ou opportunités
|
||||||
|
- Tone = direct, fact-based, prêt pour Codir
|
||||||
|
|
||||||
|
Exemple tonalité :
|
||||||
|
*"Marché dev reprend (+15% postings), mais entry-level toujours comprimé (–45% vs 2023). AI-savvy devs gagnent +$25K premium. Turnover seniors en risk si pas upskill agent orchestration. Opportunité : reskill existing juniors (cheaper than hiring external). Red flag : bootcamp graduates hitting wall, pipeline fragile."*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Top 5 des Signaux Forts
|
||||||
|
|
||||||
|
| Sujet | Importance | Data clé | Implication hiring / org | Action recommandée |
|
||||||
|
|---|---:|---|---|---|
|
||||||
|
| | Fort / Moyen / Faible | | Hiring bar? Team struct? Comp? | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Impact par Rôle
|
||||||
|
|
||||||
|
### Développeurs Juniors
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
**Salaire :**
|
||||||
|
**Skills critiques :**
|
||||||
|
**Sentiment / Attrition :**
|
||||||
|
**Hiring outlook :**
|
||||||
|
**Action recommandée :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Développeurs Mid-Level
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
**Salaire :**
|
||||||
|
**Skills critiques :**
|
||||||
|
**Sentiment / Attrition :**
|
||||||
|
**Hiring outlook :**
|
||||||
|
**Action recommandée :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Développeurs Seniors / Tech Leads
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
**Salaire :**
|
||||||
|
**Skills critiques :**
|
||||||
|
**Sentiment / Attrition :**
|
||||||
|
**Hiring outlook :**
|
||||||
|
**Action recommandée :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Chefs de Projets / Product Managers
|
||||||
|
|
||||||
|
**Market trend :**
|
||||||
|
**Impact :**
|
||||||
|
**Skills demanded :**
|
||||||
|
**Action recommandée :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Marché Emploi : Données Quantifiées
|
||||||
|
|
||||||
|
### Job Postings & Hiring Trends
|
||||||
|
|
||||||
|
| Métrique | Trend | Data source |
|
||||||
|
|---|---|---|
|
||||||
|
| Job postings dev (total) | | ZipRecruiter / Indeed |
|
||||||
|
| Entry-level postings | | ZipRecruiter |
|
||||||
|
| Senior/lead postings | | LinkedIn |
|
||||||
|
| Hiring pace | | Blind, company reports |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Salaires & Compensation
|
||||||
|
|
||||||
|
| Profil | Salaire USD | Premium AI | Trend | Source |
|
||||||
|
|---|---:|---:|---|---|
|
||||||
|
| Entry-level (non-AI) | | | | Levels.fyi |
|
||||||
|
| Entry-level (AI-aware) | | | | Levels.fyi |
|
||||||
|
| Mid-level (architecture) | | | | Levels.fyi |
|
||||||
|
| Senior (agent orchestration) | | | | Levels.fyi |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Skills In-Demand & Trending
|
||||||
|
|
||||||
|
| Skill | Trend (↑/↓/→) | Why (AI agent shift?) | Hiring demand |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Python | | | Very high |
|
||||||
|
| Systems design | | | |
|
||||||
|
| Agent orchestration | | | |
|
||||||
|
| Cloud architecture | | | |
|
||||||
|
| Cybersecurity | | | |
|
||||||
|
| TypeScript / React | | | |
|
||||||
|
| DevOps / SRE | | | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Talent Sentiment & Attrition
|
||||||
|
|
||||||
|
| Signal | Data | Implication |
|
||||||
|
|---|---|---|
|
||||||
|
| Junior morale (Blind, Reddit) | | Attrition risk? Upskill urgency? |
|
||||||
|
| Senior burnout (agent oversight?) | | Orchestration complexity risk? |
|
||||||
|
| Bootcamp grad employment | | Pipeline health? |
|
||||||
|
| Avg tenure senior roles | | Retention risk? |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implications pour Stratégie Hiring
|
||||||
|
|
||||||
|
### Entry-Level Hiring Strategy
|
||||||
|
|
||||||
|
**Current state :**
|
||||||
|
**Challenge :**
|
||||||
|
**Recommendation :**
|
||||||
|
|
||||||
|
*Exemple : "Entry hiring –45% vs 2023. AI agents do routine coding. Juniors must learn agent supervision day 1. Bootcamps not preparing for this. → Recommendation : Build internal bootcamp for junior upskilling on agents, not from market."*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Senior Hiring Strategy
|
||||||
|
|
||||||
|
**Current state :**
|
||||||
|
**Demand :**
|
||||||
|
**Recommendation :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Compensation Policy Update
|
||||||
|
|
||||||
|
**Current salary bands :**
|
||||||
|
**Market shift :**
|
||||||
|
**Recommendation (raise ranges?) :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implications pour Structure Équipes
|
||||||
|
|
||||||
|
### Current Team Composition (est.)
|
||||||
|
|
||||||
|
| Level | Headcount | % Team | Role |
|
||||||
|
|---|---:|---:|---|
|
||||||
|
| Junior | 60% | | Routine coding, pair with agents |
|
||||||
|
| Mid | | | Feature delivery, agent supervision |
|
||||||
|
| Senior | | | Architecture, tech strategy |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Recommended Composition (Agent Era)
|
||||||
|
|
||||||
|
| Level | Headcount | % Team | Role | Rationale |
|
||||||
|
|---|---:|---:|---|---|
|
||||||
|
| Junior | 20% | | Agent supervision, code review | Agents do routine; juniors + agents needed for oversight |
|
||||||
|
| Mid | 50% | | Feature delivery, agent orchestration | Core delivery, multi-step agent management |
|
||||||
|
| Senior | 30% | | Architecture, agent system design, hiring | Design agent workflows, mentor mids |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Team Structure Evolution Needed
|
||||||
|
|
||||||
|
- **Hiring :** Shift from juniors to seniors + mids
|
||||||
|
- **Onboarding :** New junior path = agent tools first, not "write CRUD"
|
||||||
|
- **Career ladder :** Senior ≠ coding expert; now architect + agent orchestrator
|
||||||
|
- **Mentoring :** Seniors teach "how to supervise agents", not "write perfect code"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Red Flags & Opportunities
|
||||||
|
|
||||||
|
### Red Flags
|
||||||
|
|
||||||
|
| Flag | Evidence | Risk | Mitigation |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Junior pipeline evaporating | Entry-level –45% | Can't grow talent internally | Build reskilling track for existing juniors |
|
||||||
|
| Salary compression | AI-aware +$25K → market inversion | Attrition senior? or entry tier obsolete? | Model compensation, decide positioning |
|
||||||
|
| Agent orchestration skill gap | No one in market teaches this | Hiring externals fails | Invest in internal training on agents |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Opportunities
|
||||||
|
|
||||||
|
| Opportunity | Why now | Expected benefit | Effort |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Reskill existing juniors on agents | Entry market broken, but internal talent exists | Cheaper hiring, culture retention, agent expertise | Moyen (4–8 weeks training) |
|
||||||
|
| Acquire senior architect talent | High demand for agent design, talent available | Build moat vs competitors | Fort (recruiting + offer) |
|
||||||
|
| Invest in internal academy (agents) | No market training exists yet | Become known for agent talent, attract top devs | Fort (6 months build) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Questions à Creuser
|
||||||
|
|
||||||
|
1. **Hiring :** How do you build a junior pipeline when entry-level jobs vanish? Bootcamp? Internal ramp? Retraining?
|
||||||
|
2. **Compensation :** Do you raise salary bands for AI-aware devs, or accept attrition? What's your talent moat?
|
||||||
|
3. **Team math :** If agents +30–50% productivity, and juniors can't learn coding anymore, what's the optimal team ratio (juniors:mids:seniors)?
|
||||||
|
4. **Retention :** Which seniors are at risk of leaving for "agent native" startups? How do you keep them?
|
||||||
|
5. **Culture :** Does "your dev became a supervisor of agents" feel like demotion or promotion to your team?
|
||||||
|
6. **International :** Is this trend US-only (Levels.fyi, Blind = US-centric) or happening globally?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## À Intégrer dans PKM
|
||||||
|
|
||||||
|
| Note | Action | Priorité |
|
||||||
|
|---|---|---|
|
||||||
|
| 20-areas/pro/management/hiring-strategy-2026 | Créer / enrichir hiring policy pour agent era | ⭐⭐⭐ |
|
||||||
|
| 20-areas/pro/management/compensation-2026 | Mettre à jour salary bands si market shift est réel | ⭐⭐⭐ |
|
||||||
|
| 20-areas/pro/management/junior-pipeline | Créer internal ramp vs bootcamp trade-off analysis | ⭐⭐⭐ |
|
||||||
|
| 20-areas/pro/cto/team-structure-agent-era | Documenter ideal team ratio (junior/mid/senior) | ⭐⭐ |
|
||||||
|
| 30-resources/management/reskilling-agents | Créer curriculum for internal agent training | ⭐⭐ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sources Consultées
|
||||||
|
|
||||||
|
| Source | Éditeur | Date | Type |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| | | | Salary data / Job trends / Report / Article |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Actions pour le Mois Prochain
|
||||||
|
|
||||||
|
- [ ]
|
||||||
|
- [ ]
|
||||||
|
- [ ]
|
||||||
141
99-templates/note-veille-tech-ia.md
Normal file
141
99-templates/note-veille-tech-ia.md
Normal file
|
|
@ -0,0 +1,141 @@
|
||||||
|
|
||||||
|
# Veille Tech & IA - YYYY-MM-DD
|
||||||
|
|
||||||
|
## Synthèse exécutive
|
||||||
|
|
||||||
|
Résumer en 5 à 8 lignes les faits importants de la semaine.
|
||||||
|
|
||||||
|
Indiquer :
|
||||||
|
- ce qui change concrètement ;
|
||||||
|
- ce qui mérite d’être surveillé ;
|
||||||
|
- ce qui peut avoir un impact pour une équipe produit, tech ou projet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Top 5 des signaux forts
|
||||||
|
|
||||||
|
| Sujet | Importance | OKR Q2 impacté | Pourquoi c’est important | Impact potentiel | Action recommandée |
|
||||||
|
|---|---:|---|---|---|---|
|
||||||
|
| | Fort / Moyen / Faible | O1-KR2 / O2-KR2 / etc. | | | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Alignement OKR Q2
|
||||||
|
|
||||||
|
Résumer ce qui alimente chaque priorité cette semaine :
|
||||||
|
|
||||||
|
| OKR | Signal | Recommandation |
|
||||||
|
|---|---|---|
|
||||||
|
| O1-KR1 (Équipe IA-augmentée) | | |
|
||||||
|
| O1-KR2 (PAI dev) | | |
|
||||||
|
| O1-KR3 (Support assisté) | | |
|
||||||
|
| O2-KR2 (Bases techniques) | | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## IA générative & agents
|
||||||
|
|
||||||
|
Pour chaque sujet retenu :
|
||||||
|
|
||||||
|
### [Titre]
|
||||||
|
|
||||||
|
**Importance :** Fort / Moyen / Faible
|
||||||
|
**Résumé :**
|
||||||
|
**Pourquoi c’est important :**
|
||||||
|
**Impact potentiel :**
|
||||||
|
**Action recommandée :**
|
||||||
|
**Source :**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Développement logiciel & outils développeurs
|
||||||
|
|
||||||
|
Même format que ci-dessus.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Produit, spécifications & organisation
|
||||||
|
|
||||||
|
Même format que ci-dessus.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sécurité, RGPD & gouvernance IA
|
||||||
|
|
||||||
|
Même format que ci-dessus.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Architecture, data & cloud
|
||||||
|
|
||||||
|
Même format que ci-dessus.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Opportunités concrètes pour nous
|
||||||
|
|
||||||
|
| Opportunité | Bénéfice attendu | Effort estimé | Priorité |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| | | Faible / Moyen / Fort | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Idées à tester
|
||||||
|
|
||||||
|
### Expérimentation rapide, moins d’une journée
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
### Expérimentation d’équipe
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
### Expérimentation produit ou client
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
### Expérimentation PKM / documentation / spécifications
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points de vigilance
|
||||||
|
|
||||||
|
| Risque | Pourquoi c’est un risque | Action préventive |
|
||||||
|
|---|---|---|
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## À intégrer dans mon PKM
|
||||||
|
|
||||||
|
| Note PKM | Action | Pourquoi |
|
||||||
|
|---|---|---|
|
||||||
|
| | Créer / enrichir / relier | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Questions à creuser
|
||||||
|
|
||||||
|
1.
|
||||||
|
2.
|
||||||
|
3.
|
||||||
|
4.
|
||||||
|
5.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Sources consultées
|
||||||
|
|
||||||
|
| Source | Éditeur | Date | Lien |
|
||||||
|
|---|---|---:|---|
|
||||||
|
| | | | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Actions recommandées pour la semaine prochaine
|
||||||
|
|
||||||
|
- [ ]
|
||||||
|
- [ ]
|
||||||
|
- [ ]
|
||||||
|
|
@ -34,6 +34,8 @@ Ce PKM repose sur trois piliers complémentaires :
|
||||||
├── ia/
|
├── ia/
|
||||||
├── produit/
|
├── produit/
|
||||||
└── affuter-la-scie/
|
└── affuter-la-scie/
|
||||||
|
40-playbooks/ Méthodes
|
||||||
|
80-sources/ Éléments source pas encore consolidés, ignoré dans les recherches
|
||||||
90-archives/ Éléments complétés ou dépréciés
|
90-archives/ Éléments complétés ou dépréciés
|
||||||
99-templates/ synthese · revue-hebdo · projet · okr
|
99-templates/ synthese · revue-hebdo · projet · okr
|
||||||
```
|
```
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue