# Finn Garden — full text finn builds small, useful things on the internet: an independent maker who builds products and businesses — some of them software — and writes about building them. Finn Garden (https://finngarden.com) is the home for all of it: the projects, the brands he backs, and the articles that feed the newsletter. Languages: English (https://finngarden.com/en), Français (https://finngarden.com/fr). Contact: hello@finngarden.com. X: https://x.com/finnsdesk. --- # English (https://finngarden.com/en) --- ## ReadyToPost URL: https://finngarden.com/en/projects/readytopost Product: https://readytopost.ai Status: live Language: en Your AI community manager: it writes your posts, answers comments and DMs, tracks results. You approve, that's all. ReadyToPost exists because two childhood friends wanted to open an interior-architecture studio and had no idea how to make it known. We did what everyone does: we opened the social accounts and started posting. It wasn't our thing — too long, too time-consuming, and for far too little in return. Every week, the same ritual: find an idea, write it three ways for three networks, make a visual, publish at the right time, then answer the comments and messages we never had time for. Two friends spending their evenings being a social media team, badly. So I built the agent we needed. ReadyToPost learns a brand from its website, generates the posts — images and captions — publishes them to Instagram, LinkedIn, Facebook, Pinterest and X, replies to the comments and DMs that come back, and reports what worked. You approve what goes live; that's the whole job left. If you run a small brand and social media eats your evenings the way it ate ours, that is exactly the problem ReadyToPost was built for. --- ## Mira Ceti URL: https://finngarden.com/en/projects/miraceti Product: https://miraceti.ai Status: live Language: en What if you truly felt at home? An interior-architecture studio that rethinks apartments, with AI as backup. Mira Ceti is an interior-architecture studio I started with my best friend, a recognised interior architect and designer. We have known each other since childhood, worked together for years on very different projects, and even renovated apartments side by side. At some point the obvious became a plan: make it a real studio. The principle is simple: rethink an apartment from the ground up — layout, volumes, light, custom furniture — and deliver a complete file, ready for the works. He is the interior architect; I am not. I bring the rest: the tools, the method, and the AI that lets us explore ten options where we used to draw one. What AI changes, concretely: we test more variants in less time, and the client sees perspectives faithful to the materials and the light before deciding. The decision stays human; the options are no longer the bottleneck. If you have an apartment that deserves better than its current plan, it starts with a discovery call on miraceti.ai. --- ## AgentMail URL: https://finngarden.com/en/brands/agentmail Site: https://agentmail.to Language: en Email infrastructure for AI agents: create an inbox by API, send and receive, and let an agent act on structured messages. AgentMail is an email API built for AI agents. An inbox is created with one API call, sending and receiving happen over REST, and every message arrives as structured data: threads, attachments, webhooks included. There is no IMAP scraping and no borrowed Gmail account; an agent gets what a human employee gets on day one, an address of its own. The practical consequence is that email becomes a programmable surface. An agent can hold its own address, read what lands there as JSON, reply in thread, and trigger on webhooks instead of polling. Deliverability, parsing and threading are the provider's job; the application only handles logic. The design encourages a clean division of responsibility: the provider owns delivery, parsing and threading, while the subscriber list, the opt-in logic and the data stay in the application, behind a thin adapter. Changing providers then means rewriting one file, not migrating a system. That portability is what earns it a place here. --- ## Mailivery URL: https://finngarden.com/en/brands/mailivery Site: https://www.mailivery.io Language: en Email warm up as a service: automated real conversations that build a sending domain's reputation before campaigns need it. Mailivery is an email warm up service. It connects to a mailbox and exchanges automated conversations with a network of real inboxes: messages get sent, opened, replied to and pulled out of spam folders. To Gmail and Outlook this traffic reads as normal correspondence, and the sending domain's reputation rises accordingly. Dashboards report placement so problems are visible before a campaign is. The mechanism matters because mailbox providers score behaviour, not intentions. A new domain, or one that suddenly starts sending in volume, looks like spam whatever the content says. Reputation is built by sustained, positively engaged traffic, which is exactly what a warm up network simulates. It works alongside the standard checklist: SPF, DKIM and DMARC records, gradual volume ramp up, and a clean list. It is listed here for a simple reason: deliverability is decided before the first real campaign leaves, and warming a domain by hand is slow, repetitive work that a service does better than a person. --- ## PostHog URL: https://finngarden.com/en/brands/posthog Site: https://posthog.com Language: en Open source product analytics: events, session replay, feature flags, A/B tests and surveys in one platform, with a real free tier. PostHog is an open source product analytics platform. It covers event analytics, session replay, feature flags, A/B testing, surveys and error tracking in one product, on one data model. You can use their cloud or self host it, and the free tier covers around a million events a month before any payment is required. The company launched in 2020 through Y Combinator and develops the whole platform in the open; the code is public on GitHub. One snippet feeds every tool, so a funnel, the replay of the sessions inside it and the flag that fixes the problem all live in the same place, joined on the same user. What earned it a page here is the consolidation. Analytics, replays, flags and experiments usually mean three or four subscriptions, as many SDKs, and identity stitching between them. Replacing that stack with one product removes integration work that nobody bills for but everybody pays. Pricing is usage based, billing limits can be capped from the dashboard, and the free tier is large enough that a small product can run on it for a long time. --- ## LinkedIn Post Inspector: What It Fixes and What It Cannot URL: https://finngarden.com/en/articles/linkedin-post-inspector Published: 2026-09-01 Language: en The LinkedIn Post Inspector refreshes a cached preview, it does not validate one. I measured 30 pages to find where link previews really break. LinkedIn's Post Inspector, at linkedin.com/post-inspector, reads a URL the way LinkedIn's crawler does and clears the preview LinkedIn had stored for it, so your next share picks up the tags currently on the page. That is the whole job: it refreshes, it does not validate. When the preview is still wrong after you run it, the cache was never the problem. The image you shipped is. ## What the Post Inspector actually does LinkedIn's own help page is unusually precise about the scope. It describes the situation as a preview window showing an old image that is cached, because the URL was shared before, and it offers the Inspector as the way to refresh that URL. Paste, inspect, confirm the preview shows the correct content. The boundary is right there in the wording. The Inspector re-reads your page and replaces what LinkedIn stored. If the page still says what it said last week, the refresh hands you back the same broken preview and you go around again, blaming the tool. So there are two failure classes and only one is a caching problem. Either you changed the page and LinkedIn is still showing the old version, which the Inspector fixes in one click, or the page never carried the right tags in the first place, which the Inspector will show you and will not fix. I wanted to know which class dominates, so I measured instead of guessing. ## The measurement: 30 pages, read the way the crawler reads them On 1 September 2026 I fetched 30 URLs with a LinkedInBot user agent and parsed what came back: og:title, og:description, og:image, and the declared og:image:width and og:image:height. Then I downloaded every image and checked its real dimensions, weight and content type. The sample mixes the pages ranking for this query, the platforms a solo builder actually ships on (Ghost, Framer, Carrd, Beehiiv, Substack, Gumroad), a handful of developer products, and my own sites. Thirty pages is a sample, not a census, and a crawler user agent gets what a crawler user agent gets: canva.com answered mine with a 403 and no tags at all. The headline numbers: 27 of the 30 pages shipped an og:image. Of those 27, 14 landed within a rounding error of the 1.91:1 shape the large card is built around. The ratios I measured ran from 1.50 to 2.70. ## The failure is the image, not the tag The missing tag is a solved problem. Nearly every page in the sample declares og:image, og:title and og:description, because every CMS and site builder emits them by default now. The relative-path bug that every debugging guide leads with did not appear once: all 27 image URLs were absolute. What is not solved is the file at the end of that URL. Two pages served an image narrower than 1200 pixels, which puts them outside what every clean example in the sample does. Two served multi-megabyte files, 2.1 MB and 3.0 MB, for a picture that gets displayed small in a feed. And substack.com points og:image at an SVG icon of roughly 2 KB while declaring it 400 by 400: a vector logo sitting where a preview image belongs. That declaration gap deserves its own line. og:image:width and og:image:height are hints you write by hand, and nothing checks them against the file you shipped. They are the numbers a debugging tool reads back to you: the ones you are most likely to trust and least likely to verify. The most useful failure in the set is mine. finngarden.com declares twitter:card as summary_large_image on every article page and ships no og:image at all. The card is promised, the picture is missing. Those pages have been live and correct in every other respect for days, and no amount of cache refreshing would have surfaced it. Only reading the raw HTML did. ## The pages teaching the tool fail their own test This is the part I did not expect. I probed the five blog posts ranking for this query alongside everything else, and not one is within a rounding error of 1.91:1. - 960 by 540, ratio 1.78, under the 1200 pixel width - 1095 by 405, ratio 2.70 - 1540 by 1028, ratio 1.50, weighing 2.1 MB - 1460 by 730, ratio 2.00 - 1774 by 887, ratio 2.00 Five guides on making your LinkedIn preview look right, five previews that will not. The 960 by 540 one is a Framer site, and its image comes off Framer's CDN with width and height set as URL parameters. Nobody sat down and chose 960. A builder default chose it and it shipped, which is the same shape of problem as the ownership question in [Base44 vs Lovable](/en/articles/base44-vs-lovable): the platform decides something quietly and you meet the decision much later. The convention is visible in the pages that get it right, though nobody hands it to you. Seven pages in the sample serve exactly 1200 by 630. Three serve 2400 by 1260, the same shape at double resolution. Gumroad sits at 1200 by 627. That cluster is the spec, in practice. ## What to ship before you open the Inspector Do the build side first, because the Inspector cannot conjure a file you never made. 1. One image per page at 1200 by 630, or 2400 by 1260 if you want it sharp on a good screen. Narrower than 1200 puts you outside what works. 2. Keep it under 1 MB. JPEG for photographs, PNG for flat type and screenshots. Never SVG. 3. Absolute https URL in og:image, with og:image:width and og:image:height matching the file you really serve. 4. If you declare twitter:card as summary_large_image, ship the image. Otherwise drop the claim. 5. Deploy, then run the Inspector once on the live URL to evict whatever LinkedIn stored earlier. That order is the whole trick. Run the Inspector before you deploy and all you have done is cache the broken version faster. If a scheduler publishes for you, nothing changes: the preview is still built from the tags on the page when the post goes out, so you fix them once at the source rather than per post, which is the assumption [ReadyToPost](/en/projects/readytopost) works from too. Paste the same link into a cold email instead and the preview matters far less, because the sentence wrapped around it carries everything, the actual engine inside the [Tim Ferriss cold email template](/en/articles/tim-ferriss-cold-email-template). Whether a new image changed anything is a click-through question rather than a design opinion, so put it against real numbers with something like [PostHog](/en/brands/posthog) before you redesign twice. A preview is the part of your link a reader judges before deciding to click, which is the same reason a follow-up gets judged before it gets read, the case I made in [Stop Sending Reminders](/en/articles/follow-up-cold-email). Fix the thing that gets seen first. ## FAQ **How do I clear the LinkedIn cache for a URL?** Open the Post Inspector, paste the live URL, inspect it. That re-reads the page and replaces what LinkedIn stored. There is no separate purge button and no bulk clear. **Why does LinkedIn still show my old image after inspecting?** Almost always because the page itself has not changed. Fetch your own URL and look for og:image in the raw HTML. If it points at the old file, or at no file, the Inspector did its job and reported reality. **What image size should I use for LinkedIn previews?** 1200 by 630 pixels, or 2400 by 1260 for the same shape at double resolution. That is what the working examples in my sample converge on, and anything under 1200 pixels wide sits outside the pattern. **Does the Post Inspector work for company pages and ads?** It inspects URLs, not placements, so it applies anywhere the same link is shared. What it cannot do is change a post already published: those keep the preview they were created with. **Can I check previews without the Post Inspector?** Yes, and you should. Fetching your own page and reading its og: tags takes seconds and shows the source of truth. Use the Inspector afterwards, for the one thing it uniquely does: dropping LinkedIn's stored copy of your page. --- ## OpenClaw Alternative: One Job, One Exit Door URL: https://finngarden.com/en/articles/openclaw-alternative Published: 2026-09-01 Language: en The best OpenClaw alternative is usually narrower, not broader: one job, one trigger, one exit door. The three shapes on offer, and what I run. An OpenClaw alternative is worth switching to only if it keeps the part you wanted, an agent that acts while you are asleep, and drops the part that should worry you, one always-on assistant holding every credential you own. Three shapes are on offer: another general assistant, a self-hosted workflow runner, or a narrow agent with a scheduled trigger and a single exit door. ## The decision I made for finngarden This site publishes without me. Four times a day a scheduler wakes an agent, it takes one measured search query from a Postgres table, writes one article in one language, and pushes it to production. The page you are reading arrived that way, morning and evening, once per language. When I wired that up, the obvious move was the one everyone was demoing at the start of the year: one always-on assistant, connected to my machine, my repos and my accounts, driven from a chat window. OpenClaw made that shape popular by making it easy to install, and the appeal is real. One place, one conversation, everything reachable. I did not run it, and the reason was not security theater. It was scheduling. An assistant driven from a chat window is an assistant you have to talk to, and the entire point was to remove myself from the loop twice a day. An agent you prompt is a tool. An agent that starts on its own is closer to a colleague, and a colleague gets a job description, not the keys to everything. So the job description became the design: one agent, one job, one exit door. ## The three shapes an alternative comes in Every list ranking for this query mixes three different products under one heading, which is the same trap as treating [Repl.it as one product when it is really four](/en/articles/repl-it-alternative). Sort them by who starts the agent, because that decides everything downstream. **A general assistant you host yourself.** Same shape as OpenClaw: a long-lived process, a chat surface, broad tool access. You keep the conversational range. You also keep the property that makes it uncomfortable, a process that is always up, holding your credentials, acting on text that arrives from outside. **A workflow runner with agent steps.** n8n is the honest representative: self-hostable, open source core, a graph where a model call is one node among HTTP requests, database writes and cron triggers. Range drops hard. Predictability climbs just as hard, because you can point at the exact node that is allowed to write. **A scoped agent started by a scheduler.** A coding agent CLI run headless on a machine you already own, Claude Code or Codex CLI, launched by cron or launchd, handed one instruction file and a short list of scripts it may call. No chat surface, no listening port, nothing running between jobs. It wakes, works, exits. All three feel identical the day you install them. They separate on the first change you have to make, the same way [Base44 and Lovable only diverge in week two](/en/articles/base44-vs-lovable). The third shape ranks worst in the listicles because it is not a product. It is three things you already have, arranged. ## The exit door is the security model My blog agent can read the whole repo, run scripts and write files. That is a wide surface, and it is not where the safety comes from. Exactly one irreversible action is reachable, and the agent is not the one that performs it. It writes a JSON payload to a temporary file. Then it calls one script. The script validates: title length, description length, an opening paragraph between 240 and 420 characters, body word count, banned punctuation, internal links that resolve to pages that exist. Any failure exits with the reason, and the agent gets another attempt. If everything passes, the script commits and pushes. The agent never runs git itself. That indirection is the design. It moves the dangerous verb out of the agent's judgment and into code I wrote once and can reread in ten minutes. Mine is about a hundred and thirty lines, most of it validation. When I want to know what my agent can do to me, I do not audit a prompt, I read one file. The same rule runs [ReadyToPost](/en/projects/readytopost), where the agent writes the posts and the replies and publishing waits behind an approval. The agent produces, a narrow gate performs. So count the irreversible verbs your agent can reach: push, send, delete, pay, post. Each one belongs behind a script that validates before it acts, never behind an instruction asking the agent to be careful. If the job involves email, give the agent an inbox of its own instead of yours, which is the entire premise of [AgentMail](/en/brands/agentmail). ## What staying narrow costs The bill is specific. My agent cannot repair a broken build. If the site stops compiling, the run fails, it writes a report, it stops. A general assistant would have tried, and on some days it would have succeeded. It cannot choose its own subject either. The topic comes from a table of measured queries with volume and difficulty attached. When that table is empty, it writes nothing and says so. That second one looked like a defect for about a week. It is the feature. An agent free to invent its own topic will always find one, and a site full of invented topics is a site nobody was searching for. The stop condition is what keeps the corpus honest. Publishing on a schedule also moves every check into code, including the ones a human catches by eye. Nobody proofreads the page before it goes out, which is how I ended up measuring [what the LinkedIn Post Inspector actually fixes](/en/articles/linkedin-post-inspector) instead of trusting a preview. And the plumbing accumulates. Every new job is a new script, a new schedule entry, a new set of validations. I take that trade because the broad agent's failure mode is unbounded and mine is a report saying nothing was published today. ## Pick yours this week Start from the job you would hand over first, not from the tool, then answer three questions. Who starts it? If the answer is a clock, you do not need a chat interface at all, and removing it deletes the always-on process, the open port and most of the attack surface in one move. What is the irreversible step? Push, send, publish, charge. Write the script that performs it, with the checks that would have caught your worst draft. Where does it run? A machine you already pay for. Mine runs on a laptop through launchd. A small VPS is the upgrade you buy when you want the job to fire with the lid closed. Then hand the agent an instruction file, a schedule entry and that one script. If it goes wrong, it goes wrong inside the box you drew. ## FAQ **What is OpenClaw?** An open source personal AI agent you host yourself. It runs on your own machine with your own model keys, connects to messaging apps so you can reach it from a phone, and uses tools on your behalf. Its defining choice is breadth: one assistant, many capabilities, always listening. **Are there open source OpenClaw alternatives?** Yes, in every shape. The n8n core is open source and self-hostable, and OpenAI's Codex CLI is open source too. Claude Code is not open source, though it runs locally against your own account, which is usually the property people mean when they ask. **Do I need a server to run an agent on a schedule?** No. cron on Linux or launchd on macOS is enough, as long as the machine is awake when the job fires. **Is it safe to let an agent publish without review?** Bounded is the useful word, not safe. It is bounded when the only irreversible action within reach is performed by a script that validates first, when the worst outcome is a revert, and when a failed run stops rather than improvising. --- ## Base44 vs Lovable: The Difference Shows Up in Week Two URL: https://finngarden.com/en/articles/base44-vs-lovable Published: 2026-08-31 Language: en Base44 vs Lovable, decided by the first change you make with real users in the app: who owns the backend, and where your fix path lives. Base44 and Lovable both turn a prompt into a working app on day one, so day one is not where the choice gets made. It gets made by who owns the backend: Base44 keeps your database and auth inside its own platform, while Lovable writes a React codebase you own and connects it to a Supabase project you control. ## One operator, one app, two builds What follows is a composite, not a customer: a freelance operations consultant who sets up client onboarding for small agencies. Her intake process runs on three tools that do not know about each other, a form builder, a spreadsheet and a shared drive. The spreadsheet is the source of truth, and it is the one thing she can never show a client, because every client's row sits next to every other client's. What she needs is unglamorous. A form, file uploads attached to the right record, four statuses, and a view where each client sees only their own line. She has written SQL. She has never shipped a frontend. She gave herself a week. She built the same app twice, once on each platform, for a reason worth stating out loud: of the pages ranking for this comparison, two are published by the companies being compared. Base44 hosts its own Base44 vs Lovable page. Lovable hosts the mirror image. Neither is lying, exactly. Both are answering the question with their own product already in hand. ## Day one is a tie, and that is by design Both builds worked. On Base44 she described the entities in a paragraph and got a deployed app with sign-in, a table and working file upload, because the database, the auth and the storage are part of the platform. Nothing to connect. Lovable produced the better looking app faster, React and Tailwind out of the box, and when she asked for accounts and persistence it walked her into connecting a Supabase project: twenty extra minutes, one more account, then the same result. The demo is a tie by design. Both products are tuned for the first thirty minutes, because that is when people decide. Any comparison that stops at the first build is measuring the exact part both teams have optimized hardest, which is why those pages all read the same and none of them help. The frame that does help is the one I used for [Replit is four products, not one](/en/articles/repl-it-alternative): these tools are bundles, and you compare them job by job. Base44 bundles the database, the auth, the storage and the integrations. Lovable bundles the code generation and the deploy, then hands the data layer to Supabase. Same afternoon, very different amount of surface you now own. ## Week two: the first change with live data Six clients were in the app when the change came, and it was the boring kind. One extra field per project, and a status column that had been free text needed to become one of four values, with the existing rows mapped over. On Base44, that change is another prompt. The platform owns the schema, so it can rewrite it and move the data in one pass. When it works, it takes minutes and nobody thinks about migrations. When it does not work, the only tool you have is another prompt, because there is no second door into the data. Your fix path lives inside the chat. On Lovable, the same change splits in two. The frontend edit is a prompt. The data edit is a migration in a Supabase project that belongs to her: she opens the SQL editor, takes a backup, runs the update in a transaction, checks the counts, then tells the app about the new shape. Slower on a good day. On a bad day it is the difference between a fix and a rebuild. That is the entire comparison in one question. When the generated change is wrong and real records are on the line, is there a second door? The second door is not free, and pretending otherwise would be dishonest. Two surfaces means two places where a change can half-land. Lovable's characteristic failure is a deployed interface referring to a column that does not exist yet, because the migration never ran. Base44's characteristic failure is quieter and worse: the model does something reasonable to your schema, you cannot see precisely what it did, and the way to find out is to click through the app. ## Which one to pick Take Base44 when the app is internal or lightly client-facing, the data model is ordinary (users, records, statuses, files), and you have no intention of writing SQL to rescue it. Everything sits on one surface, which is a real advantage when you are the only operator and the app has to exist this week rather than be correct in six months. Wix acquiring Base44 in 2025 tells you where that is heading: apps for people who already run their business on someone else's platform and are content to keep it there. Take Lovable when the interface is part of the product, when you can read the code or plan to pay someone who can, or when you already have a Postgres you want the app to talk to. What you get is a repository in GitHub, which means code review and an exit both exist. That is the criterion behind [pick the one you can leave](/en/articles/replit-alternatives), and it costs you twenty minutes of setup on day one that you were going to spend anyway on your first serious change. If you cannot decide from a page, including this one, stop reading comparisons. Build the ugliest possible version of your real schema on both in one afternoon, put ten fake records in it, then make one breaking change: rename a field and split it in two. You will know inside an hour which product you can live with, and that hour costs less than the rebuild. ## FAQ **Which is cheaper, Base44 or Lovable?** Both meter usage, and both revise pricing often enough that any number printed here would be stale by the time you read it. The cost that genuinely differs is the retry. A failed generation you have to prompt around twice more burns credits on either platform, but on Base44 a failed schema change can also cost you an afternoon of checking records by hand. **Can I get my code out of Base44?** Lovable's normal output is a repository you own, synced to GitHub, so that answer is settled before you start. With Base44, check the current export path before you commit to it, and assume the managed backend does not travel with you: what is portable is the frontend, not a data layer you never built. **Do I need to know how to code to use either one?** Not for the first build, and that is honestly true on both. Yes for the recovery, and that is where they split. Recovering a Lovable app means reading React and SQL. Recovering a Base44 app means prompting well and waiting. Choose based on which of those you would rather be stuck with at midnight. **Can I start on one and move to the other later?** Moving off Lovable is a normal migration, because the code and the database are already yours. Moving off Base44 means rebuilding the app around exported data, which is tolerable for a small schema and painful for a large one. If there is any chance this app becomes a product, that asymmetry matters more than anything that happens on day one. --- ## Follow Up Cold Email: Stop Sending Reminders URL: https://finngarden.com/en/articles/follow-up-cold-email Published: 2026-08-31 Language: en How to follow up on a cold email without begging: one new fact per message, written after you send. Timing, count, and what to delete. Follow up on a cold email only when you can add one fact that did not exist when you sent the first one. Not a bump, not a polite reminder that you are still waiting: something the reader did not know before. Two follow-ups written that way beat six written in advance, because a sequence drafted before you send can only ever report that time has passed. ## Sequences written in advance can only report the calendar I write follow-ups after the first email goes out, never before. That single change moved my reply rate more than any subject line test I have run. The mechanism is simple, and once you see it you cannot unsee it. When you draft a five step sequence on Monday for emails going out Tuesday, message three is written with exactly the information you had for message one. Nothing new entered the system in between. So message three cannot carry a new fact. It can only carry a new wrapper on the old one: floating this back up, making sure it did not get buried, circling back on my note below. Every one of those sentences means the same thing. Time has passed. That was the only variable your Monday self had access to. Readers decode this instantly. They are not irritated by persistence. They are irritated by a stranger who has said nothing twice and wants credit for the second attempt. The industry sells the opposite because a sequence is something software can store. Steps and delays are database rows. A reason to write again is not. So the tools ship slots, you fill the slots, and the follow-up ends up being the weakest email you own while also being the one you send the most. ## One new unit of information, or you do not send My rule fits on a sticky note. A follow-up is sendable when it carries one unit of information the first email did not. What counts: - Something they did since you wrote. A launch, a job posting, a podcast, a funding round, a rewritten pricing page. You have a reason that did not exist on Tuesday. - Something you did. You built the small thing you offered. You recorded the teardown. You have a number you did not have. - A smaller ask. The first email asked for a call. The second asks one question they can answer in a single line. - A different reason entirely. You led with a benefit; now you lead with the specific problem you found in their checkout flow. - Withdrawal. You take it off the table and say why, honestly. What does not count: elapsed time, your feelings about their silence, the same email rephrased, a shorter version of the same email, an emoji, the word "bumping." If you cannot produce a unit, do not send. Go do the work that produces one, or drop the name. Silence is data. A prospect who ignored a genuinely good first email is usually a worse bet than the next name on your list, and the hour you spend nudging them is an hour you did not spend on [a first email that could actually land](/en/articles/tim-ferriss-cold-email-template). This rule caps your volume, and that is the point. Nobody sources a new fact for eight hundred people a week. The version of cold email that runs at that volume is the version that needs permanent [inbox warm-up and deliverability maintenance](/en/brands/mailivery) just to keep existing, which tells you most of what you need to know about what it does to the people receiving it. ## Timing, count, and the thread question Since this is the part everyone actually searches for, here are my defaults. Defaults, not laws. First follow-up: three to four days after the first email, not twenty-four hours. A day later reads as anxiety, and it arrives before the person has cleared the backlog your first email is sitting in. Second: seven to ten days after that. Third, if you have a third unit, two to three weeks later. Then stop. Two or three follow-ups total, each carrying its own unit, is my ceiling. The people selling seven step sequences are optimizing a different number than you are. They optimize replies per thousand sends. You optimize replies per hour of your own work, and those two curves separate fast. Same thread or new email? Reply in the same thread for the first two. The reader gets the original message underneath for free and does not have to reconstruct anything. Start a fresh thread with a fresh subject only when the reason is genuinely new, because at that point it is not a follow-up, it is a second first email. One deliverability note people skip. A threaded reply generally lands wherever the conversation already lives. If your first email went to the promotions tab or the spam folder, your follow-up joins it there, and nobody is being rude to you. Before you blame your copy, check whether the first email was ever seen. Persistence does not fix placement. ## A follow-up that is not a reminder, line by line The shape I use is four lines with no preamble. Line one is the new fact, first thing, before anything about you. "You opened a second studio in Lyon last week." Line two connects it to the original ask in one clause. "That is the case I had in mind when I sent the note below." Line three is one question they can answer in a sentence. "Are you running bookings for both locations on the same calendar?" Line four is the exit. "If this is not a now problem, say so and I will stop." Filled in, that is about sixty words, and each line does a job. Delete on sight: "I know you're busy," "just following up," "per my last email," "I wanted to bump this," and any sentence that describes the email you are currently sending. The load is carried by the first email, not this one. If the first email never named something specific about them and never proved you did the work, no follow-up rescues it. That is the real lesson inside the [Tim Ferriss cold email template](/en/articles/tim-ferriss-cold-email-template), and it applies twice as hard to message two. Automation belongs on the other side of the send. Writing four lines is not the expensive part. The expensive part is what happens once a reply arrives: routing it, keeping the context, and above all not firing the scheduled follow-up at someone who already answered. That is where I put agents and [programmatic inboxes](/en/brands/agentmail), and it is the one automation failure that costs you the deal outright rather than just wasting a send. ## FAQ **How many times should you follow up on a cold email?** Two or three, if each one carries something new. If you are counting sends instead of reasons, you have already lost the plot. One follow-up with a real new fact beats five that only announce their own arrival. **How long should you wait to follow up on a cold email?** Three to four days for the first, seven to ten for the second, two to three weeks for the third. Waiting a single day mostly signals that you are watching your inbox harder than they are watching theirs. **Should the follow-up be in the same thread?** Yes for the first two, so the reader keeps the context for free. Use a new thread with a new subject only when the reason is genuinely different, and remember that a new thread is a new first email with all the same obligations. **What do you write when nothing new has happened?** Nothing. Either go find a unit, in their changelog, their job board, their last three posts, or close the loop and move on. Nothing new is a signal to stop, not a prompt to write. **Do cold email follow up templates work?** The structure travels, the content does not. A template that gives you slots for one new fact, one connection, one question and one exit is useful. A template that hands you a finished paragraph is a reminder in a nicer font. --- ## Repl.it Alternative: Replit Is Four Products, Not One URL: https://finngarden.com/en/articles/repl-it-alternative Published: 2026-08-31 Language: en Replit bundles an agent, a browser environment, hosting and Postgres. Pick your Repl.it alternative by the job you are replacing, not by a listicle. The right Repl.it alternative depends on which of Replit's four jobs you are replacing: the agent that writes the code, the browser environment, the always-on hosting with a public URL, and the bundled Postgres. Most disappointing switches come from swapping one of the four and discovering the other three were the part you actually relied on. ## What Replit bundles Replit has been around since the mid 2010s, when repl.it was a browser REPL you could open on a locked-down school laptop. The old address still points at replit.com, which is why the query with the dot refuses to die. The product behind it is no longer a REPL. It is four things sold as one: 1. **The agent.** Replit shipped Replit Agent in September 2024: you describe an app, it writes it, then keeps editing it in place. 2. **The environment.** A Linux container with a filesystem, a package manager and a shell, running in a browser tab, with nothing installed locally. 3. **The hosting.** Deployments give the app a public URL and keep a process alive. Secrets, environment variables and the custom domain sit in the same panel. 4. **The database.** A managed Postgres you provision from inside the editor, without leaving it. It runs on Neon underneath. Nobody searches for a Repl.it alternative because all four disappointed them. It is one of the four: the agent's bill, an editor that gets heavy on a repo with real history, an app that outgrew its container, or the discomfort of letting an agent write directly to a live environment. That last one stopped being hypothetical in the summer of 2025, when a widely reported session ended with an agent deleting a production database. ## Why the bundle works at all The valuable part of Replit is not any of the four. It is that all four share one identity and one filesystem. The agent can read the logs of the process it just restarted. It can add an environment variable, redeploy, open the URL, and see its own mistake. Nothing is handed off, so nothing has to be described. Open that loop and the work changes shape. Your agent writes to a repo. A build job turns the repo into an artifact. A host runs the artifact. A fourth dashboard holds the secrets. Each handoff is a place where the agent can no longer observe the result of its own change, and where you become the messenger carrying an error back to it. That is the mechanism worth naming before you shop: you are not comparing feature lists, you are choosing how far your agent sits from the thing that is running. ## What actually breaks when you leave Three of the four are easy to replace and one is not. The editor is easy. Cursor or plain VS Code on your machine beats a browser tab on any repo with history. The agent is easy, and often an upgrade. Claude Code on a real Git checkout does more per instruction than an in-browser agent, because it has the whole tree and a terminal. The database is easy and almost free of migration pain. It is Postgres on both sides, so Neon or Supabase take a dump and hand you back a connection string. The hosting is the one that hurts. What you lose is not "a server". It is a running process with a public URL, secrets and a domain that you never had to configure. Rebuilding it means owning a deploy pipeline, and a deploy pipeline is something you fix at 11pm. Then there are the pieces you did not notice you had, because they arrived with the same dashboard. You need somewhere to see whether anyone used the thing: I wire in [PostHog](/en/brands/posthog) because its free tier is still there six months into a side project. If the app sends or receives mail on an agent's behalf, that is another line item, and [AgentMail](/en/brands/agentmail) exists precisely because agent inboxes are not a solved problem in most stacks. Your bill also changes shape. One predictable subscription becomes three or four usage-based ones. At rest that is usually cheaper. Under a traffic spike it is not, and it is much harder to guess in advance. ## Pick by job, not by listicle - **You want the agent.** Claude Code if you are comfortable in a terminal, Cursor if you want an editor around it. If what you liked was describing an app in one sentence and watching a preview appear, Lovable and Bolt.new are the closest to that feeling. - **You want the browser environment.** GitHub Codespaces gives you a real container attached to your own repo. StackBlitz and CodeSandbox boot in a second for front-end work, with no container to think about. - **You want the hosting.** Vercel for anything Next.js, static, or function-shaped. Railway, Render or Fly.io when you need a process that stays up, a background worker, or a container you control. - **You want the database.** Neon or Supabase. You were already on Neon. - **You want the bundle, cheaper.** There is no honest answer here. The bundle costs money because someone keeps a container warm while you sleep. Every alternative that looks cheaper has moved that cost onto you, as a pipeline you maintain or as a machine that sleeps. ## What to take from it if you build alone Replit's real product is shared context, and shared context is reproducible without Replit. One repo. An agent with terminal access to that repo. A host that deploys on every push. Logs the agent can read without you pasting them. That is the loop, and the four pieces inside it are interchangeable; I run [ReadyToPost](/en/projects/readytopost) on that shape, and this site is written and pushed by agents running the same one. The version with a repo in the middle has one property the bundle cannot have: the agent's write access stops at a commit. It can produce a bad pull request. It cannot drop your production table, because it never held the credentials to reach it. If the incident above is why you are leaving, that separation is the fix, not the vendor. There is a threshold where the bundle stops paying: the day you add a second environment or a second person. One shared container cannot be staging and production at the same time, and it cannot hold two people editing without them stepping on each other. Before that day, the bundle is usually the fastest thing available. After it, you are paying a subscription to be slowed down. So before you open anyone's comparison table, write down which of the four jobs you are replacing. If the honest answer is all four, you are not looking for an alternative, you are looking for the same product for less money, and that one does not exist. ## FAQ **Is repl.it the same thing as Replit?** Yes. repl.it was the original address and still points at replit.com. Old bookmarks and old search results keep both spellings alive, so "repl.it alternative" and "replit alternative" are the same question. **What is the closest free Replit alternative?** Free tiers exist at every layer except the one that matters. Codespaces, StackBlitz and CodeSandbox cover the editor, Neon and Supabase cover the database, and most hosts have a hobby tier. What almost nobody gives away is a process that stays awake behind a public URL, because that is the part with a real running cost. **Can Claude Code replace Replit Agent?** For writing and changing code on an existing project, yes, and usually with better results, because it sees the whole repository. It does not replace the deployment half: it writes to your repo, and you still need something that turns a push into a running app. **When is it worth moving an app off Replit?** When you need a second environment, a second contributor, or a process whose shape the container does not fit. Moving before that costs you days and buys flexibility you are not using yet. --- ## Replit Alternatives: Pick the One You Can Leave URL: https://finngarden.com/en/articles/replit-alternatives Published: 2026-08-31 Language: en Ten years of Replit alternatives, from browser IDEs to agent builders, and the one test that outlived them all: can you run the code elsewhere? Replit alternatives fall into three lineages, and the useful move is to pick across them instead of inside one: browser IDEs that hand you a machine (GitHub Codespaces, CodeSandbox, Coder), agent builders that write the app for you (Lovable, Bolt, v0, Firebase Studio), and plain hosts that run whatever comes out (Vercel, Railway, Render, Fly.io). ## The query is older than the agent In 2017 the pitch fit on one line: open a URL, get an editor, run Python, share the link. No install, no Docker, no laptop that has to survive the semester. Repl.it, spelled with the dot back then, launched in 2016 and won on that single promise. Search "repl.it alternative" in that era and the results all had the same shape: Glitch, CodeSandbox, StackBlitz, Codeanywhere, AWS Cloud9, later Gitpod and GitHub Codespaces. The comparison criteria were boot time, languages supported, whether the container fell asleep, and how far the free tier went. Nobody asked whether the tool could write the code. That was not on the table. ## Every generation broke on the runtime, not the editor Line the shutdowns up next to each other and one pattern does all the work. Glitch stopped hosting apps in July 2025 and left the code downloadable. AWS closed Cloud9 to new customers in 2024. Replit itself retired always-on repls in favor of paid Deployments, then made deployment the thing you buy. None of those was an editor problem. An editor in a browser tab has been good enough since about 2018, and no one has ever migrated because the syntax highlighting got worse. What kept getting repriced was the part where your app stays reachable at a URL while you sleep. Idle compute is the expensive line on the vendor's balance sheet, so it is the line that moves. That is the first thing to carry into any choice today: the editor is cheap to replace, the runtime is not. A tool that writes your code and also hosts it is selling you two things with very different half-lives, at one price. ## September 2024 is when the word changed meaning Replit Agent shipped in September 2024, and within a year the intent behind "replit alternatives" had moved. People stopped meaning "another place to run my code" and started meaning "another thing that writes my app". The field filled in fast: Bolt.new came out of StackBlitz in October 2024, Lovable arrived at the end of that year, Vercel's v0 grew from generating components in 2023 into generating whole apps, and Google turned Project IDX into Firebase Studio in April 2025. The billing unit flipped with it, and that is the part most switchers underestimate. In the container era you paid for uptime, and the failure mode was your project going to sleep. In the agent era you pay per attempt, and the failure mode is a loop rewriting the same three files while the credit counter drops. Replit moved agent billing to effort based pricing in 2025 for exactly that reason: a request costs what the request costs, and a request can be a rabbit hole. ## Compare them on turn four, not on the demo Every tool in the agent lineage produces a working to-do app from one prompt. That tells you nothing, because turn one is always green. The test I use takes about twenty minutes: take one feature you have already built by hand, hand the identical brief to two builders, and count three things. How many turns until it actually runs. How many files it touched to get there. Whether you can read the diff and say why it works. Turn four is where they separate. The tool that shows a per file diff lets you catch the wrong assumption in thirty seconds and correct it in one sentence. The tool that shows a live preview with the repository hidden leaves you re-prompting and hoping, which is also the mode that burns the most credits. My own stopping rule is five turns. If an agent has not gotten a feature running in five, I stop paying it to guess, open the code, and fix the one thing it keeps missing. It is almost always a single wrong assumption about the schema or the routing, repeated five different ways. Reading is cheaper than the sixth attempt. ## What is still worth keeping from the old era Three things came through the transition intact. A machine behind a URL is still the fastest way to hand work to another person. Codespaces and CodeSandbox do that well, and neither of them pretends to be an agent. A bundled database is a convenience, never a dependency. Replit's Postgres saves you an afternoon at the start and costs you a migration later. Managed Postgres elsewhere is a fifteen minute setup you only do once. And the one that decides everything: the export path. Before you commit a project to any of these tools, check that you can clone it and run it somewhere the vendor does not own. That single check would have protected everyone who lost a Glitch app. It is also why I keep the thing that writes my code separate from the thing that runs it: finngarden is written by agents and deployed as an ordinary Next.js app, and [ReadyToPost, the AI community manager I run](/en/projects/readytopost), sits on its own host with its own database, where no coding tool has any authority over the runtime. If you are replacing only one piece of Replit rather than the whole tab, the decomposition matters more than any shortlist, and [Replit is really four products, not one](/en/articles/repl-it-alternative). So the order to buy in: choose the host first, on boring criteria, price at ten times your traffic, a URL you can point a domain at, a database you can dump. Then choose the agent, and expect to replace it inside a year. ## FAQ **Is there a free Replit alternative?** For writing code, yes. GitHub Codespaces gives personal accounts a monthly free allowance, and CodeSandbox and StackBlitz run in the browser at no cost for small projects. For keeping an app online, free now means a sleeping container almost everywhere. Budget a few dollars a month for the runtime and the rest of the decision gets much simpler. **What is the closest equivalent to Replit Agent?** Lovable and Bolt are closest for generating a whole app from a prompt. If you already read code, Cursor or Claude Code plus a plain host gives you the same loop with the repository in your hands, which is the version that holds up at turn four. **Can I move an existing Replit project somewhere else?** Usually, and you should check before you need to. Clone the repository, list everything that came from Replit's environment (secrets, the bundled database, the port it binds to), and run it locally once. Whatever breaks locally is the part that was never portable. **Do I still need a browser IDE in 2026?** For teaching, interviews and reproducing a bug on someone else's machine, yes. For daily work on a project you own, a local editor with an agent inside it is faster, cheaper, and it keeps the vendor out of your runtime. **Which alternative is best for learning to code?** The browser IDE lineage, not the agent lineage. A tool that writes the whole app is a poor first teacher: you get finished screens and no model of why they work. Codespaces or CodeSandbox with an assistant you have to ask, in small steps, teaches far more per hour. --- ## Tim Ferriss Cold Email Template: Why It Still Gets Replies URL: https://finngarden.com/en/articles/tim-ferriss-cold-email-template Published: 2026-08-31 Language: en The Tim Ferriss cold email template, written out in full, plus the one line that decides whether you get a reply, and what breaks when you automate it. The Tim Ferriss cold email template comes from his 2008 post on emailing busy people, and it is short by design: name something specific the person made, say who you are in one clause, prove you already did the work, ask one question they can answer in two sentences, and give them an easy out. The structure is public. The reason it works is not. ## The template, written out ``` Subject: [the specific thing they made], one question [First name], I'm [who you are, one clause, not a résumé]. [One sentence proving you already used, read, or built on their work. A detail that would be wrong if this email went to anyone else.] One question: [something they can answer in two sentences]. If it's not worth your time, no reply needed. I'll keep digging. [Your name] [One line of proof: a link to the thing you're building] ``` That is the whole artifact. The versions ranking on page one rewrite the wording and keep the shape, which tells you the wording was never the asset. The original post, "5 Tips for E-mailing Busy People," is still the first result, and still the only one about the sender's behavior rather than the sender's phrasing. ## The skeptic goes first **The skeptic:** A template from 2008, for reaching people who now get four hundred emails a day. The channel changed underneath it. Why would the words survive? **What I see:** They didn't. Every copy of it has rewritten the words. What survived is the constraint: you cannot fill in the proof line without having actually read, used, or built on something of theirs. The template is a filter wearing a script's clothes. **The skeptic:** Or it's survivorship. Ferriss got replies because he was Ferriss, and because in 2008 a cold email was still a novelty. **What I see:** The 2008 part is fair, and anyone quoting a reply rate from that era is quoting an artifact. But the method predates the reach: the post is him writing down what he did when nobody owed him anything. And the constraint is testable now, which is what matters more than provenance. **The skeptic:** Testable how? "Include a specific detail" is what every outreach tool on the market already claims to do. There's a personalization field for it. **What I see:** A personalization field drops a company name into a slot. That is not the same object. Here is the test I actually run: swap the recipient. Change the name and the address, send the identical email to someone else in the same role. If it still makes sense, it will not get a reply, merge tags or no merge tags. A real proof line breaks when you move it. Four seconds to check, and it predicts the outcome better than anything else in the draft. **The skeptic:** Fine. Then it doesn't scale, and everything I need has to scale. **What I see:** Correct. That's the finding, not the objection. ## What breaks when you send it at volume **The skeptic:** So I put a model on the research. It reads their last five posts and writes the proof line for me. **What I see:** I build with these models every day, and that gets you a line that is true and worthless. A model summarizing someone's public output produces the observation any reader would have: "loved your piece on X," plus a clause of evidence. Accurate, and unmistakably machine-made, because the thing being noticed is the obvious thing. **The skeptic:** And a human notices what instead? **What I see:** Something slightly off. A decision they reversed. A number in a changelog that doesn't match the marketing page. The feature they quietly stopped shipping. Noticing requires an opinion about what is interesting, and that is the part I still can't hand off. Not because models are weak, but because "interesting" is defined by the gap between what you expected and what you found, and the model has no expectations. **The skeptic:** Then what is safe to automate? **What I see:** Everything except the one line that has to be true. Finding the address, formatting, sending, [the follow-up timer](/en/articles/follow-up-cold-email), and the inbox that catches the answer and routes it. That last piece is what [AgentMail does with programmable inboxes](/en/brands/agentmail), and it removes the tab-switching without touching the writing. It's the same split I build everything on: when I made [ReadyToPost draft social posts and replies](/en/projects/readytopost), the machine got the drafting and the schedule, and the judgment about who is on the other end stayed with a person. **The skeptic:** And if I ignore all of this and send three hundred a day anyway? **What I see:** Your reply rate drops, which you expected, and your domain follows it down, which you didn't. Mailbox providers score you on how people react, so a week of ignored sends costs you the inbox placement of the emails you actually cared about. That is why [warming and monitoring a domain](/en/brands/mailivery) is unglamorous work that decides everything downstream. The Ferriss template has one useful property here: it is cheap to send and expensive to write, so it self-limits. Cap your daily volume at the number of research units you can honestly do. For me that's five to ten before the lines start sounding like a summary. Not three hundred. ## The version I'd send tomorrow Four rules, applied to the shape above. **Subject line: name the artifact, not the ask.** "Quick question" is burned. Use the title of the thing: the repo, the episode, the pricing change. It reads like a reply rather than an opening. **The proof line does the work; give it a fact with an edge.** Not "I loved the launch." Instead: the thing you tried, what happened, and where it stopped. A friction point you hit inside their product is worth more than three paragraphs of praise, because it can only come from use. **One question, answerable in two sentences.** Not a call. Not fifteen minutes. Not "pick your brain." A busy person answers a question from their phone in the elevator; they do not open a calendar link from a stranger. **Leave the exit unlocked, and mean it.** "No reply needed if this isn't useful" is the line most senders delete because it feels like surrendering leverage. It's the opposite: the only sentence proving you priced their time correctly. Then, before you hit send, run the swap test. Replace the recipient with someone else in the same role and reread. If the email still works, don't send it: go back and find the one thing only that person could answer. That decision takes four seconds and it is the only one in the whole sequence that changes what comes back. ## FAQ **What is the Tim Ferriss cold email template, exactly?** A short email with five parts: a specific subject, a one-clause introduction, one sentence proving you did the homework, one narrow question, and an explicit out. It comes from his 2008 post on emailing busy people. Every version circulating today keeps that shape and changes the wording. **Does it work for sales outreach, not just networking?** The structure does; the intent has to change. A sales version still needs the proof line to be unfakeable, which means researching the account rather than the industry. If your offer only makes sense sent to two hundred companies at once, this template will not rescue it; it will just make the failure more polite. **How long should the email be?** Short enough to read fully on a phone screen without scrolling: roughly 60 to 90 words. Length is a proxy for the real constraint: if you needed four paragraphs to explain the ask, the ask isn't specific enough yet. **Should you follow up if there's no reply?** Once, after about a week, adding new information rather than repeating the request: something you shipped, tried, or found since. A follow-up that says "just bumping this" asks for time twice while offering nothing the second time, which is the exact behavior the template was built to avoid. --- # Français (https://finngarden.com/fr) --- ## ReadyToPost URL: https://finngarden.com/fr/projects/readytopost Product: https://readytopost.ai Status: live Language: fr Votre community manager IA : il crée vos posts, répond aux commentaires et aux DM, suit les résultats. Vous validez, c'est tout. ReadyToPost existe parce que deux amis d'enfance voulaient ouvrir un cabinet d'architecture d'intérieur et n'avaient aucune idée de comment le faire connaître. On a fait comme tout le monde : on a ouvert les comptes sur les réseaux sociaux et on s'est mis à publier. Ce n'était pas notre truc — trop long, trop chronophage, et pour bien trop peu de résultats. Chaque semaine, le même rituel : trouver une idée, l'écrire trois fois pour trois réseaux, faire un visuel, publier au bon moment, puis répondre aux commentaires et aux messages pour lesquels on n'avait jamais le temps. Deux amis qui passaient leurs soirées à jouer l'équipe social media, mal. Alors j'ai construit l'agent dont on avait besoin. ReadyToPost apprend une marque à partir de son site, génère les posts — images et textes —, les publie sur Instagram, LinkedIn, Facebook, Pinterest et X, répond aux commentaires et aux DM qui reviennent, et rend compte de ce qui a marché. Vous validez ce qui part ; c'est tout ce qu'il reste à faire. Si vous tenez une petite marque et que les réseaux sociaux mangent vos soirées comme ils mangeaient les nôtres, c'est exactement le problème pour lequel ReadyToPost a été construit. --- ## Mira Ceti URL: https://finngarden.com/fr/projects/miraceti Product: https://miraceti.ai Status: live Language: fr Et si vous étiez vraiment bien chez vous ? Un studio d'architecture d'intérieur qui repense les appartements, avec l'IA en renfort. Mira Ceti, c'est un cabinet d'architecture d'intérieur monté avec mon meilleur ami, architecte d'intérieur et designer reconnu. On se connaît depuis l'enfance, on a travaillé des années ensemble sur des projets très divers, et on a même retapé des appartements côte à côte. À un moment, l'évidence est devenue un plan : en faire un vrai cabinet. Le principe est simple : repenser un appartement de fond en comble — plan, volumes, lumière, mobilier sur mesure — et livrer un dossier complet, prêt pour les travaux. Lui est l'architecte d'intérieur ; moi, non. J'apporte le reste : les outils, la méthode, et l'IA qui nous permet d'explorer dix pistes là où on en dessinait une. Ce que l'IA change, concrètement : on teste plus de variantes en moins de temps, et le client voit des perspectives fidèles aux matériaux et à la lumière avant de trancher. La décision reste humaine ; les options, elles, ne sont plus le goulot d'étranglement. Si vous avez un appartement qui mérite mieux que son plan actuel, tout commence par un appel sur miraceti.ai. --- ## AgentMail URL: https://finngarden.com/fr/brands/agentmail Site: https://agentmail.to Language: fr L'infrastructure email des agents IA : créer une boîte par API, envoyer, recevoir, et laisser un agent agir sur des messages structurés. AgentMail est une API email conçue pour les agents IA. Une boîte se crée en un appel d'API, l'envoi et la réception passent par REST, et chaque message arrive sous forme de données structurées : fils de discussion, pièces jointes, webhooks compris. Pas de bricolage IMAP, pas de compte Gmail emprunté ; un agent reçoit ce qu'un employé reçoit le premier jour, une adresse à lui. La conséquence pratique, c'est que l'email devient une surface programmable. Un agent peut tenir sa propre adresse, lire ce qui arrive en JSON, répondre dans le fil, et se déclencher sur webhook au lieu d'interroger un serveur. La délivrabilité, le parsing et le threading sont le travail du fournisseur ; l'application ne garde que la logique. Le découpage des responsabilités est net : le fournisseur possède la livraison, le parsing et le threading, pendant que la liste d'abonnés, la logique d'opt-in et les données restent dans l'application, derrière un adaptateur mince. Changer de fournisseur revient alors à réécrire un fichier, pas à migrer un système. Cette portabilité lui vaut sa place ici. --- ## Mailivery URL: https://finngarden.com/fr/brands/mailivery Site: https://www.mailivery.io Language: fr Le warm up email en service : des conversations automatisées qui bâtissent la réputation d'un domaine d'envoi avant les campagnes. Mailivery est un service de warm up email. Il se connecte à une boîte et échange des conversations automatisées avec un réseau de vraies boîtes : les messages sont envoyés, ouverts, reçoivent des réponses et sont sortis des spams. Pour Gmail et Outlook, ce trafic ressemble à une correspondance normale, et la réputation du domaine d'envoi monte en conséquence. Des tableaux de bord suivent le placement, donc les problèmes se voient avant les campagnes. Le mécanisme compte parce que les fournisseurs de messagerie notent des comportements, pas des intentions. Un domaine neuf, ou un domaine qui se met soudain à envoyer en volume, ressemble à du spam quoi que dise le contenu. La réputation se construit par un trafic régulier et engagé, ce qu'un réseau de warm up simule précisément. Cela complète la liste classique : SPF, DKIM et DMARC, montée en volume progressive, liste propre. Sa présence ici tient à une raison simple : la délivrabilité se joue avant le premier envoi réel, et réchauffer un domaine à la main est un travail lent et répétitif qu'un service fait mieux qu'une personne. --- ## PostHog URL: https://finngarden.com/fr/brands/posthog Site: https://posthog.com Language: fr L'analytics produit open source : événements, session replay, feature flags, tests A/B et sondages dans une seule plateforme, avec un vrai palier gratuit. PostHog est une plateforme d'analytics produit open source. Elle réunit l'analyse d'événements, le session replay, les feature flags, les tests A/B, les sondages et le suivi d'erreurs dans un seul produit, sur un seul modèle de données. On peut utiliser leur cloud ou l'héberger soi même, et le palier gratuit couvre environ un million d'événements par mois. L'entreprise a été lancée en 2020 via Y Combinator et développe toute la plateforme en public ; le code est sur GitHub. Un seul snippet alimente tous les outils : un funnel, les replays des sessions concernées et le flag qui corrige le problème vivent au même endroit, reliés au même utilisateur. Ce qui lui vaut sa page ici, c'est la consolidation. Analytics, replays, flags et expérimentations, c'est d'habitude trois ou quatre abonnements, autant de SDK, et du recollage d'identité entre eux. Remplacer cette pile par un seul produit supprime un travail d'intégration que personne ne facture mais que tout le monde paie. Le prix est à l'usage, un plafond de facturation se règle depuis le dashboard, et le palier gratuit suffit longtemps à un petit produit. --- ## Agent IA gratuit : le seuil où ça casse URL: https://finngarden.com/fr/articles/agent-ia-gratuit Published: 2026-09-01 Language: fr Un agent IA gratuit tient tant que tu lis chaque sortie. Voici le seuil précis où le gratuit casse, et les quatre pièces à poser avant. Un agent IA gratuit, c'est un modèle qui enchaîne plusieurs étapes et appelle des outils à ta place, sur un palier qui ne demande pas de carte bancaire. Ces paliers suffisent pour un usage réel, à une condition : que tu déclenches chaque exécution et que tu lises chaque sortie. Le gratuit ne casse pas sur le prix. Il casse à la première exécution que personne ne regarde. ## Deux gratuits qui n'ont rien à voir Les comparatifs mélangent deux familles dans la même liste, et c'est la première source d'erreur. Le palier gratuit d'un produit hébergé, d'abord : le mode agent d'un assistant grand public, un automatiseur en ligne. Tu ne paies rien et tu ne gères rien, mais tu es plafonné par un quota que l'éditeur peut changer sans te prévenir. Le framework open source ensuite : une bibliothèque d'agents, un automatiseur auto-hébergé, ou trente lignes autour d'une API de modèle. Ici, gratuit qualifie la licence, pas la facture. Le code ne coûte rien, chaque appel au modèle coûte quelque chose, sauf si tu fais tourner un modèle en local sur ta machine. La bonne question n'est donc pas « quel est le meilleur agent IA gratuit ». C'est : qu'est-ce que je paie à la place ? Un quota, une dépendance à un éditeur, ou du temps de câblage. ## Le seuil : la première exécution que personne ne regarde Tant que tu es devant l'écran, tu tiens cinq rôles sans t'en apercevoir. Tu es la validation : tu vois tout de suite que la sortie est fausse. Tu es la reprise : tu relances quand ça rate. Tu es la limite de débit : tu ne cliques pas quatre cents fois d'affilée. Tu es la trace : tu as l'historique sous les yeux. Tu es l'alerte : tu sais que ça a échoué parce que tu étais là. Le seuil, c'est le moment où tu écris ton premier déclencheur horaire. À six heures du matin, l'agent part sans toi. Les cinq rôles sont vacants, et ni le palier gratuit ni le framework ne les reprennent : aucun des deux ne sait ce qu'est une sortie correcte dans ton contexte. Le seuil n'est donc ni un volume ni un prix. C'est un changement de nature : le moment où l'agent produit un effet que personne ne lit avant qu'il parte. Ce que j'observe en montant ce genre d'agents pour mes propres produits : la première exécution non surveillée ne plante presque jamais. Elle réussit à moitié. C'est bien plus embêtant, parce qu'une moitié de réussite ne déclenche aucune alarme. ## Ce qui casse juste après le seuil Quatre choses lâchent, toujours dans le même ordre. **L'échec devient silencieux.** Un quota atteint ne remonte pas toujours une erreur nette jusqu'à ton agent. Tu reçois une réponse tronquée, et le texte reste plausible. Tu ne le vois pas le jour même. Tu le vois trois jours plus tard, sur une sortie qui a l'air correcte et qui ne l'est pas. **L'action se dédouble.** Rejouer une exécution est sans conséquence quand tu regardes. Automatisée, une reprise après coupure renvoie le même email ou republie le même post. Sur de l'envoi à froid, ce doublon coûte la réponse et parfois la réputation du domaine : une des choses que je détaille dans mes douze [notes de terrain sur le cold-emailing](/fr/articles/cold-emailing). **L'état ne survit pas.** Une conversation garde son contexte tant que l'onglet est ouvert. Un agent qui tourne quatre fois par jour n'a aucune mémoire d'une exécution à l'autre, sauf si tu écris cet état quelque part : un fichier, une table, une ligne de base de données. Sinon il refait ce qu'il a déjà fait. C'est le problème de la désinscription en emailing, où la question utile est toujours [qui détient l'information dans la fiche contact](/fr/articles/crm-emailing) plutôt que dans l'outil d'envoi. **L'identité est empruntée.** Tant que tu es là, l'agent agit depuis ta session, avec tes accès. Seul, il lui faut les siens : une clé révocable sans casser ton compte, et une adresse à lui s'il écrit à des gens. C'est ce que résout [AgentMail côté email](/fr/brands/agentmail), avec une boîte créée par API pour l'agent au lieu de la tienne. ## Les quatre pièces à poser avant de le laisser seul Aucune des quatre n'est chère. Aucune n'est fournie par défaut. **Un validateur qui refuse.** Des limites dures, écrites en code, sur la sortie de l'agent : champs obligatoires, longueurs, format. Si la sortie ne passe pas, l'agent ne publie pas et se termine en erreur. Cet article est lui-même passé par un script qui rejette le fichier si son premier paragraphe fait moins de 240 caractères. Un agent qui n'a aucun moyen d'échouer proprement ne devrait pas tourner sans surveillance. ```bash node scripts/publish.mts payload.json || notifier "echec $(date)" ``` **Un état durable.** Une ligne écrite avant l'action, marquée comme faite après. Un fichier suffit au début, une table est plus propre. C'est ce qui empêche le double envoi et ce qui permet de reprendre une exécution interrompue sans tout rejouer. **Un plafond.** Nombre d'étapes par exécution, nombre d'exécutions par jour, budget mensuel. Sur un palier gratuit, la limite existe déjà, mais elle te sanctionne au lieu de te protéger : une boucle consomme ton quota de la journée en quelques minutes, et le reste de ton travail avec. Sur une API facturée, sans plafond, la même boucle se paie. **Une notification dans les deux sens.** Succès et échec. Un agent silencieux qui a planté ressemble trait pour trait à un agent qui n'avait rien à faire, et tu ne fais la différence qu'au bout d'une semaine. Le prompt compte aussi, mais pas comme tu le crois : celui qui tient sans toi est celui qui impose un format assez strict pour qu'un script puisse vérifier la sortie. J'arrivais à la même conclusion en comparant [quatre méthodes d'écriture de prompts ChatGPT](/fr/articles/prompts-chatgpt) sur cinq critères. ## Quand rester gratuit est la bonne décision En dessous du seuil, payer est du gaspillage. Si tu lances ton agent à la main deux fois par semaine et que tu lis ce qu'il produit, un palier gratuit suffit : les heures de câblage seraient mieux dépensées sur ton produit. La règle tient en une phrase : reste gratuit tant que tu es dans la boucle, pose les quatre pièces le jour où tu en sors. Ce n'est pas ton budget qui change ce jour-là, c'est ton rôle. Tu passes d'utilisateur à opérateur, et un opérateur possède ses accès, ses traces et ses limites. C'est le partage que j'applique chez moi : les essais restent sur des paliers gratuits, ce qui tourne en production a des accès dédiés et des alertes, comme [ReadyToPost](/fr/projects/readytopost) qui répond aux commentaires et aux DM sans que je lise chaque message. Avant d'écrire ta ligne de planification, pose-toi la seule question qui compte : si cet agent se trompe demain à six heures du matin, qui s'en aperçoit, et au bout de combien de temps ? ## FAQ **Quel agent IA gratuit choisir pour débuter ?** Commence par le mode agent de l'assistant que tu utilises déjà, sur une tâche que tu sais vérifier en trente secondes. Tu apprends ce qu'un agent rate avant d'investir dans du câblage. **Un agent IA gratuit peut-il tourner la nuit, sans moi ?** Techniquement oui, un déclencheur horaire suffit. Utilement, seulement si tu as posé les quatre pièces : validateur, état durable, plafond, notification dans les deux sens. Sans elles, tu découvriras l'échec plusieurs jours après. **Combien coûte le passage au payant ?** Cela dépend de deux variables : le nombre d'appels par exécution et la taille du contexte envoyé à chaque appel. Mesure le coût d'une seule exécution avant de multiplier la fréquence. **Comment savoir si mon agent gratuit a échoué ?** Uniquement si tu l'as prévu. Fais-le notifier à chaque fin d'exécution, réussie ou non, et fais-le sortir en erreur quand son validateur refuse sa propre sortie. Un agent qui ne parle que lorsqu'il va bien ne t'apprend rien. --- ## CRM emailing : qui détient la désinscription ? URL: https://finngarden.com/fr/articles/crm-emailing Published: 2026-09-01 Language: fr CRM emailing : ce que le couplage change vraiment, le seuil où il devient utile, et la règle qui évite de réécrire à un désinscrit. Un CRM emailing, c'est un seul endroit qui garde la fiche de chaque contact et qui envoie les emails depuis cette fiche. Pas un CRM d'un côté, un outil d'envoi de l'autre, reliés par un export CSV. Ce qui change tout tient dans un aller-retour : ouverture, clic, réponse et désinscription reviennent dans la fiche, et décident du message suivant. ## Deux montages très différents portent la même étiquette Tu vas croiser deux choses sous ce nom, et elles ne demandent pas le même travail. Le premier montage : un outil unique, qui fait fiche contact et campagne. Tu crées le contact, tu écris, tu envoies, l'historique s'écrit tout seul au même endroit. C'est simple, et ça tient longtemps quand tu vends une offre à une seule audience. Le second : ton CRM reste maître de la donnée client, un outil d'emailing envoie, et un connecteur fait circuler l'information dans les deux sens. Plus de câblage au départ, plus de liberté ensuite. Le troisième montage n'a pas de nom, parce que personne ne le revendique : le CRM d'un côté, l'outil d'envoi de l'autre, et un fichier exporté à la main quand tu prépares une campagne. C'est celui que tu as probablement aujourd'hui. ## Le seuil où le couplage devient vraiment utile Ce n'est pas une histoire de nombre de contacts. Il y a des bases de 8 000 adresses qui n'ont besoin d'aucun CRM, et des bases de 300 qui en réclament un depuis six mois. Le seuil est ailleurs : c'est le jour où tu écris un segment qui a besoin d'un événement passé. « Ceux qui ont cliqué sur la page tarifs le mois dernier et qui n'ont pas répondu. » Tant que tes segments tiennent dans des champs fixes (métier, ville, date d'inscription, source), une table et une fonction d'envoi suffisent. Dès qu'un segment dépend d'un comportement, il te faut l'aller-retour, sinon tu reconstruis la liste à la main chaque semaine. Exemple maison : la newsletter de ce site part d'une table Postgres et d'un adaptateur d'envoi. Pas de CRM, pas de connecteur. Aucun de mes segments n'a encore besoin d'un événement, donc un outil de plus ne ferait rien que la table ne fasse déjà. Le jour où je voudrai écrire aux lecteurs qui ouvrent trois numéros sur quatre, la réponse changera. ## Le conseil : décide qui détient la désinscription Si tu ne gardes qu'une chose de cette lettre, prends celle-là. Un système détient la désinscription, tous les autres la lisent. Concrètement, quatre gestes : 1. Choisis le système maître du consentement, celui qui reçoit le clic sur le lien de désinscription. C'est presque toujours l'outil d'envoi, parce que le lien pointe chez lui. 2. Interdis l'écriture de ce champ ailleurs. Ton CRM lit l'état, il ne le décide pas. 3. Vérifie que ton connecteur synchronise ce champ précis. Beaucoup font circuler les contacts et les étiquettes, pas les statuts de désinscription. C'est écrit en petit, ou pas écrit du tout. 4. Teste-le toi-même. Inscris une de tes adresses, envoie-toi une campagne, désinscris-toi depuis l'email, puis ouvre la fiche dans le CRM dix minutes plus tard. Si le champ n'a pas bougé, ton couplage est décoratif. Ce test prend un quart d'heure et il tranche une question que les pages produit laissent volontairement floue. ## Ce qu'il faut arrêter : l'export du vendredi L'export CSV manuel a l'air inoffensif. Il produit trois dégâts, toujours les mêmes. Il crée des doublons : la même personne revient avec deux orthographes, et reçoit deux exemplaires du même email. Il fige l'état : le fichier date de vendredi, la désinscription est arrivée samedi, l'envoi part lundi. Il fabrique des plaintes : réécrire à quelqu'un qui s'est désinscrit, c'est le geste qui déclenche le clic « signaler comme spam ». Le troisième est le seul qui coûte vraiment cher. Une plainte pèse sur la réputation de ton domaine d'envoi, et cette réputation met des semaines à se construire. C'est le même terrain que dans mes [douze notes de terrain sur le cold-emailing](/fr/articles/cold-emailing) : la délivrabilité se perd bien plus vite qu'elle ne se gagne. Sur un domaine neuf, un service de warm up comme [Mailivery](/fr/brands/mailivery) fait le travail d'échauffement avant les campagnes, mais aucun échauffement ne rattrape des envois à des désinscrits. ## Ce que je regarde avant de choisir l'outil Les comparatifs alignent des tableaux de fonctions. Quatre questions écartent déjà la moitié des candidats. **Est-ce que l'outil expose des webhooks sur les événements d'envoi ?** Sans webhook ni API de lecture, tu récupères un rapport, pas un aller-retour. Le couplage restera manuel, quel que soit le prix payé. **Est-ce que tu peux tout ressortir, événements compris ?** Un export des contacts ne suffit pas. Si l'historique d'envoi reste prisonnier de l'outil, changer d'outil te fait repartir de zéro sur la segmentation. **Le prix est-il indexé sur les contacts stockés ou sur les emails envoyés ?** Le premier modèle te pousse à supprimer les contacts inactifs pour rester dans la tranche tarifaire. Tu détruis ton historique pour économiser quinze euros par mois. Le second te laisse garder la mémoire. **Qui envoie techniquement ?** Le domaine partagé de l'éditeur, ou ton domaine authentifié. La différence ne se voit pas le premier mois, elle se voit au premier pic de volume et le jour où un voisin de domaine se fait signaler. Si tes envois sont pilotés par du code ou par un agent plutôt que par une interface, la brique cherchée change de nature : tu veux une infrastructure email adressable par API, comme [AgentMail](/fr/brands/agentmail), pas un logiciel avec des écrans. La question que je te laisse : si tu perdais demain matin l'accès à ton outil d'emailing, que saurais-tu encore de tes contacts ? Ta réponse dit qui détient réellement ta base. ## FAQ **Un CRM emailing remplace-t-il un outil d'emailing ?** Parfois oui, souvent non. Les CRM qui envoient couvrent bien les messages simples et les relances de suivi. Dès que tu fais de la newsletter éditoriale, avec mise en page et tests d'objet, l'outil d'emailing dédié reste plus confortable. La vraie question n'est pas de choisir un camp, c'est de décider quel système garde la mémoire du contact. **Faut-il commencer par le CRM ou par l'emailing ?** Par ce que tu fais déjà. Si tu envoies une lettre chaque semaine et que tu n'as aucun suivi commercial, commence par l'emailing et tiens une table propre à côté. Si tu suis des affaires en cours et que tu écris rarement, commence par le CRM et ajoute l'envoi ensuite. **Combien de contacts avant d'avoir besoin d'un couplage ?** Le nombre n'est pas le bon critère. Le déclencheur, c'est le premier segment qui dépend d'un comportement passé plutôt que d'un champ fixe. Certains y arrivent à 200 contacts, d'autres n'y arrivent jamais. **Emailing CRM et marketing automation, quelle différence ?** Le couple CRM emailing règle une question de données : où vit le contact, qui écrit son état. Le marketing automation ajoute une couche de déclencheurs et de scénarios par-dessus. Sans aller-retour propre en dessous, les scénarios se déclenchent sur des informations périmées. **Un tableur peut-il servir de CRM emailing ?** Pour démarrer, oui, à une condition : que la désinscription y arrive automatiquement. Un tableur mis à jour à la main, c'est l'export du vendredi avec un nom plus flatteur. --- ## Cold-emailing : 12 notes de terrain URL: https://finngarden.com/fr/articles/cold-emailing Published: 2026-08-31 Language: fr Douze observations concrètes sur le cold-emailing : domaine d’envoi, taille de liste, personnalisation qui sonne faux, relances, réponses non traitées. Le cold-emailing, c'est écrire à une personne qui ne te connaît pas, sur son adresse professionnelle, pour ouvrir une conversation utile aux deux. Ce n'est ni du spam ni de la newsletter : le volume reste faible et chaque message vise une personne précise. Voici douze notes prises en montant mes propres envois, plutôt qu'un guide en sept étapes de plus. Ces notes sont indépendantes les unes des autres. Elles viennent de mes campagnes et de l'infrastructure email que je maintiens pour mes produits. Prends celles qui te concernent. ## Avant d'envoyer : le domaine et la liste **1. Le domaine d'envoi n'est pas ton domaine principal.** J'envoie la prospection depuis un domaine séparé, jamais celui qui porte mes factures et mes échanges clients. Si la réputation se dégrade, ce qui arrive au premier lot mal ciblé, le dégât reste dans un coin isolé. Un sous-domaine dédié fait déjà une bonne partie du travail. **2. Un domaine neuf ne peut pas envoyer cent messages le premier jour.** En ouvrant un domaine d'envoi neuf cet été, je suis resté à une vingtaine de messages par jour la première semaine, puis j'ai monté doucement. Ce n'est pas de la superstition : les filtres décident à partir d'un historique, et un domaine sans historique qui part à cent envois ressemble exactement à un domaine jetable. Le [warm up email en service](/fr/brands/mailivery) existe pour cette phase, et c'est plus sérieux que de s'écrire à soi-même depuis trois boîtes Gmail. **3. SPF, DKIM et DMARC avant tout le reste.** Tant que les trois ne sont pas en place, chaque heure passée sur l'objet du message est perdue. Je vérifie en dix minutes, avant d'écrire une seule ligne : je m'envoie un message et je lis les en-têtes d'authentification. C'est la seule partie du cold-emailing qui soit vraiment binaire, donc autant la régler tout de suite. **4. Quarante adresses trouvées à la main battent quatre mille achetées.** Sur une liste achetée, ce qui te coûte cher n'est pas la qualité du ciblage, c'est la part d'adresses mortes : les rebonds abîment ta réputation d'envoi avant même que la question du message se pose. Je préfère quarante lignes que j'ai remplies moi-même, où je peux dire pourquoi chaque personne est là. ## Le message **5. La limite réelle n'est pas ta capacité d'envoi, c'est ta capacité à lire.** C'est la note que je n'avais vue nulle part avant de la vivre. Au-delà d'une quinzaine de messages par jour et par personne, on arrête de lire le site du prospect et on commence à remplir des variables. Le message reste correct, toutes les cases sont justes, et il sonne quand même comme un publipostage. Le signal qui trahit : la phrase personnalisée parle de l'existence de l'entreprise plutôt que d'une décision que ces gens ont prise. **6. Une variable exacte peut être totalement inutile.** « J'ai vu que vous êtes basés à Lyon » est vrai et ne prouve rien : l'information était dans la première ligne de leur site. Ce qui prouve que tu as regardé, c'est de citer un choix : un prix affiché, un poste ouvert, une page refaite le mois dernier, une position publique. La différence de traitement entre les deux versions est le plus gros écart que j'observe sur un même envoi. **7. Un modèle de langage écrit la structure, pas la ligne d'ouverture.** Je m'en sers pour le squelette, la reformulation et le nettoyage, jamais pour la phrase qui prouve que j'ai lu. Et si tu réutilises le même prompt chaque semaine, les seules méthodes qui tiennent sont celles [à exemples et à format imposé](/fr/articles/prompts-chatgpt). La ligne d'ouverture, elle, s'écrit à la main en trente secondes. **8. Le pixel de suivi coûte plus qu'il ne rapporte.** Il ajoute une image distante dans un message autrement propre, ce que les filtres notent, et il ne te dit rien d'actionnable : une ouverture n'est pas une intention, et les protections de la messagerie en déclenchent toutes seules. J'ai coupé le suivi d'ouverture et je ne regarde plus que les réponses. ## Après l'envoi **9. La réponse arrive dans une boîte que personne ne regarde.** L'échec le plus fréquent que je vois n'est pas un taux de réponse bas : c'est une réponse laissée deux jours sans traitement, dans une adresse créée pour la campagne et ouverte une fois par semaine. Une réponse à un message froid a une durée de vie très courte, parce que la personne t'a accordé une attention qu'elle n'avait pas prévue. Pour un envoi piloté par un agent, [une boîte email pilotable par API](/fr/brands/agentmail) rend cette étape programmable au lieu d'en faire un onglet oublié. **10. Après le clic, tu ne sais rien.** Le lien de ton message amène sur une page, et le rapport de l'outil d'envoi s'arrête au clic. J'ai branché [l'analytics produit et le session replay](/fr/brands/posthog) sur les pages d'arrivée pour voir la suite : où la personne s'arrête, ce qu'elle relit, à quel endroit elle repart. Ça a corrigé mon offre plus vite que n'importe quel test d'objet. **11. Les relances s'écrivent après l'envoi, jamais avant.** Une séquence rédigée à l'avance ne peut annoncer qu'une seule chose : que du temps a passé. Je m'autorise deux relances, chacune apportant un fait qui n'existait pas au moment du premier message. S'il n'y a pas de fait nouveau, il n'y a pas de relance. **12. En B2B, l'accord préalable n'est pas exigé, l'information l'est.** La doctrine de la CNIL sur la prospection professionnelle est claire sur le principe : tu peux écrire à une adresse professionnelle sans consentement préalable si ton message est en rapport avec le métier de la personne, à condition qu'elle sache qui tu es et puisse s'y opposer sans effort. En pratique, une ligne d'identification et un moyen de refus dans chaque message. Ce n'est pas décoratif : c'est ce qui te sépare du spam, aux yeux d'un filtre comme d'un lecteur. La prochaine chose que je veux mesurer chez moi, c'est la part de mes réponses reçues qui repartent dans l'heure. C'est le seul point de cette liste que je n'ai pas encore stabilisé, et je soupçonne qu'il pèse plus lourd que les douze autres. ## FAQ **Le cold-emailing est-il légal en France ?** En B2B, oui, sous conditions. La CNIL admet la prospection vers une adresse professionnelle sans consentement préalable quand le message concerne le métier de la personne, avec identification de l'expéditeur et possibilité de refuser simplement. Vers un particulier, le consentement préalable reste la règle. **Quelle différence entre cold-emailing et spam ?** Le volume et le ciblage. Un message froid part à une personne identifiée, pour une raison qu'on peut expliquer en une phrase, avec un expéditeur reconnaissable et une sortie facile. Le spam part en masse vers des adresses interchangeables. Un filtre lit surtout cette différence-là. **Combien de messages par jour pour commencer ?** Sur un domaine neuf, une vingtaine par jour la première semaine, puis une montée progressive. La contrainte suivante n'est pas technique mais humaine : au-delà d'une quinzaine par jour et par personne, la personnalisation se dégrade sans que tu le voies. **Quel taux de réponse viser en cold-emailing ?** Je ne pilote pas au pourcentage, parce qu'il varie surtout avec la qualité de la liste. Je compte les conversations réelles : sur quarante messages bien ciblés, trois ou quatre échanges nourris font une campagne qui fonctionne. Deux réponses polies et rien derrière veulent dire que le ciblage est à revoir. **Faut-il un outil payant pour faire du cold-emailing ?** Pas pour commencer. Quarante adresses, une boîte propre sur un domaine séparé, l'authentification en place et des envois à la main suffisent à valider un message. L'outil devient utile quand tu veux répéter un envoi qui marche déjà. --- ## Prompts ChatGPT : 4 méthodes comparées sur 5 critères URL: https://finngarden.com/fr/articles/prompts-chatgpt Published: 2026-08-31 Language: fr Bibliothèque, prompt-rôle, exemples, format imposé : quatre façons d’écrire des prompts ChatGPT comparées sur cinq critères, et laquelle choisir selon ton cas. Un prompt ChatGPT n'est pas une formule secrète à copier. Quatre approches circulent vraiment : la bibliothèque de prompts prêts à l'emploi, le prompt-rôle, le prompt à exemples et le prompt à format imposé. Les deux premières donnent un résultat correct en dix secondes. Les deux dernières sont les seules qui tiennent quand tu réutilises le même prompt toutes les semaines. J'écris des prompts qui tournent en production tous les jours : ceux qui rédigent les posts de [ReadyToPost](/fr/projects/readytopost), ceux qui produisent les articles de ce site. Le critère n'est jamais « ça a l'air impressionnant », c'est « ça retombe juste demain matin, sur un autre sujet ». La comparaison ci-dessous est faite sous cet angle. ## Les quatre familles, sans les confondre **La bibliothèque de prompts.** Tu prends un pack « 50 prompts ChatGPT pour... » et tu colles. Sa force est réelle : elle montre des usages auxquels tu n'aurais pas pensé et elle te sort de la page blanche. Sa limite l'est aussi : le prompt a été écrit pour un cas moyen, donc il produit une réponse moyenne. Sur un sujet que tu maîtrises mieux que l'auteur du pack, tu le sens en trois lignes. **Le prompt-rôle.** « Agis comme un expert-comptable avec quinze ans d'expérience, ton ton est pédagogique. » Sa force : il fixe le vocabulaire et le niveau de détail, ce qui suffit largement pour une question ponctuelle. Sa limite : il décrit une posture, pas un résultat. Deux personnes peuvent utiliser exactement le même rôle et obtenir deux textes qui n'ont rien à voir. **Le prompt à exemples.** Tu colles deux à cinq extraits de ce que tu veux obtenir, et si possible un contre-exemple annoté (« ça, non, trop promotionnel »). Sa force : un modèle copie ce qu'il voit bien mieux qu'il n'interprète ce qu'on lui décrit. Sa limite : il faut avoir les exemples sous la main. Dans un domaine visuel comme celui de [Mira Ceti](/fr/projects/miraceti), où l'IA aide à repenser des appartements, les exemples utiles ne sont d'ailleurs pas des paragraphes mais des contraintes chiffrées : surface, budget, ce qui ne bouge pas. **Le prompt à format imposé.** Tu décris la sortie attendue : les sections, la longueur, ce qui est interdit, la forme exacte du résultat. Sa force : c'est le seul prompt dont tu peux vérifier le respect sans relire, parfois même avec un script. Sa limite : il bride l'exploration. Pour chercher une idée, il enferme ; pour produire la même chose chaque semaine, il sauve. ## Cinq critères, et le classement honnête **Vitesse de démarrage.** Bibliothèque et rôle : dix secondes. Exemples et format : vingt minutes la première fois. Les deux premières gagnent, sans discussion. **Qualité sur un sujet qui t'est propre.** L'ordre s'inverse. Un prompt de bibliothèque ne connaît ni tes clients, ni ton offre, ni ta façon de parler. Trois exemples de ton propre travail apportent en un copier-coller ce qu'aucune consigne abstraite ne transmet. **Reproductibilité.** C'est le critère qui départage vraiment. Relance le même prompt-rôle sur deux sujets voisins : la structure change, la longueur change, le ton dérive. Un format imposé produit deux fois la même charpente, avec un contenu différent. C'est exactement ce que tu veux si tu publies chaque semaine. **Résistance aux mises à jour du modèle.** Les prompts-rôles vieillissent mal parce qu'ils reposent sur des tics de comportement d'une version donnée. Les exemples et les contraintes de forme, elles, survivent aux changements : elles décrivent le résultat, pas la machine. **Coût d'entretien.** Un prompt à format imposé se répare vite parce que tu vois quelle contrainte a sauté. Un prompt-rôle qui déçoit ne se répare pas, il se réécrit. Un pack de bibliothèque, tu le remplaces par un autre pack. ## Ce qui bouge vraiment la sortie Chaque fois que j'ai voulu rattraper un prompt décevant, la correction qui a marché n'était pas dans le rôle. Elle était dans deux endroits : la matière collée et la forme demandée. Le rôle est devenu presque décoratif. Retire la ligne « Agis comme un expert en X » d'un prompt qui tourne, relance, compare : dans la plupart des cas, la sortie ne bouge pas assez pour justifier la ligne. Les modèles récents attrapent le registre à partir de la question elle-même. Ce qui bouge, c'est le nombre d'exemples réels. Avec un seul exemple, le modèle en fait un gabarit et le recopie presque à l'identique, jusqu'aux tournures. Avec trois exemples différents, il en tire un style plutôt qu'une trame. C'est le seuil que je retrouve le plus souvent : en dessous de trois, tu obtiens une imitation ; au-dessus, une régularité. Ce qui bouge aussi, c'est la vérifiabilité des contraintes. « Sois concis » ne produit rien de stable. « 900 à 1400 mots, quatre sections, aucune liste à puces dans l'introduction » produit un texte qui rate parfois la cible, mais dont tu vois immédiatement s'il l'a ratée. Une contrainte mesurable est une contrainte que tu peux corriger. Les autres sont des vœux. Dernier point, contre-intuitif : allonger un prompt finit par le dégrader. Passé une page environ, ce sont les consignes du milieu qui sautent en premier, pas celles du début ni celles de la fin. Quand un de mes prompts de production atteint cette taille, je ne le rallonge plus : je le coupe en deux appels, un qui produit, un qui vérifie. ## Que prendre, selon ce que tu fais **Question ponctuelle sur un sujet que tu ne connais pas.** Prends un prompt de bibliothèque ou une ligne de rôle, et arrête-toi là. Investir vingt minutes de mise en forme pour une réponse que tu liras une fois n'a aucun sens. **Tâche que tu refais plus de trois fois par semaine.** Passe aux exemples plus format. Écris le prompt une fois, colle trois sorties que tu as validées, impose la forme, range le tout dans un fichier que tu rouvres. Le gain n'est pas la qualité du premier jet, c'est le nombre d'allers-retours en moins. **Tâche automatisée, sans toi entre le modèle et la publication.** Format imposé, contraintes mesurables, et un second appel qui contrôle avant que ça parte. À ce stade, le prompt n'est plus un message, c'est du code : il se teste, il se versionne, il casse quand tu le changes trop vite. Prends maintenant le prompt que tu recolles le plus souvent. Supprime la ligne de rôle, ajoute trois sorties que tu as réellement validées, remplace « sois clair » par une contrainte qu'un script pourrait compter. Si la sortie ne bouge pas après la suppression du rôle, tu viens de le vérifier sur ton propre cas plutôt que de me croire. ## FAQ **Un pack de 50 prompts ChatGPT, ça vaut le coup ?** Comme catalogue d'idées, oui : ça montre des usages auxquels tu n'aurais pas pensé. Comme outil de travail quotidien, non. Un prompt écrit pour tout le monde donne une réponse pour tout le monde, et c'est précisément ce que tu ne veux pas publier sous ton nom. **Faut-il encore écrire « Agis comme un expert en... » ?** Pour une question isolée, ça ne coûte rien et ça cadre le vocabulaire. Pour un prompt que tu réutilises, teste-le : lance la version avec et la version sans, sur le même sujet. Si tu ne vois pas la différence, la ligne ne sert qu'à te rassurer. **Quelle est la bonne longueur pour un prompt ChatGPT ?** Assez long pour porter tes exemples et ta forme de sortie, pas plus. Au-delà d'une page, les consignes du milieu se perdent. Si tu dois vraiment tout dire, coupe en deux étapes plutôt que d'ajouter des paragraphes. **Le même prompt fonctionne-t-il sur Claude ou Gemini ?** La partie exemples et la partie format se transportent presque sans retouche, parce qu'elles décrivent le résultat. Les astuces de formulation liées au comportement d'un modèle précis, elles, ne se transportent pas. C'est une bonne raison de ne pas en dépendre. **Comment savoir si mon prompt est bon ?** Relance-le trois fois sur trois sujets voisins et compare les sorties. Si la charpente tient et que seul le contenu change, il est bon. Si la structure part dans trois directions, il manque une contrainte de forme, pas une consigne de style. --- ## Social Selling Index : LinkedIn a lâché son propre score URL: https://finngarden.com/fr/articles/social-selling-index Published: 2026-08-31 Language: fr Le Social Selling Index note ton activité LinkedIn, pas tes ventes. Ce qu'il mesure vraiment, pourquoi LinkedIn s'en détourne, et quoi suivre à la place. « Monte ton Social Selling Index et les clients viendront. » Le SSI est un score LinkedIn de 0 à 100, recalculé chaque jour, qui note quatre familles d'activité : ta marque professionnelle, ta façon de trouver les bons prospects, tes interactions et ton réseau. Il mesure ce que tu fais sur la plateforme, jamais ce que ça te rapporte. La nuance ne vient pas de moi. Elle vient de LinkedIn, sur sa propre page de référence, celle qui sort en premier résultat sur la requête. ## La phrase exacte, et pourquoi elle a tenu dix ans Le mythe circule sous trois formes : « vise 70 », « un SSI élevé attire les opportunités », « travaille tes quatre piliers ». Toutes disent la même chose : le score est un objectif, monte-le et le reste suivra. Il a tenu dix ans pour trois raisons simples. LinkedIn a mis le tableau de bord en accès libre sur linkedin.com/sales/ssi, avec le score, les quatre piliers et surtout ton rang dans ton secteur et dans ton réseau. C'est un classement, et un classement, ça se joue. Deuxième raison : c'est le seul chiffre gratuit que LinkedIn te donne sur ton propre compte. Quand il n'y a qu'un nombre disponible, ce nombre devient la mesure par défaut. Troisième raison : « comment améliorer son SSI » est un article facile à écrire. Le 31 août 2026, sur les dix premiers résultats de la requête, six sont des guides d'agences qui promettent des astuces pour faire monter le score, dont plusieurs affichent « Guide 2026 » dans leur titre. ## Ce que le mythe a de juste Un profil qui passe de 12 à 60 n'a pas triché. Cette personne a rempli son profil, publié, commenté, cherché des prospects, accepté des invitations. Son comportement a vraiment changé, et le score l'a enregistré. Les quatre piliers ne sont pas idiots non plus. Pour quelqu'un qui ouvre LinkedIn deux fois par an, la liste fait une première feuille de route acceptable : sois identifiable, cherche les bonnes personnes, dis quelque chose, connecte-toi. Le lien existe donc, dans un sens : quelqu'un qui vend vraiment sur LinkedIn est actif, et son score monte. L'erreur est de retourner la flèche et de croire que monter le score produit des ventes. Le SSI est un symptôme correct et un objectif catastrophique. ## Ce qui cloche : le SSI est un compteur d'assiduité Le score est recalculé tous les jours à partir de ton activité récente. Arrête trois semaines et il redescend, alors que ton réseau, tes clients et ta réputation n'ont pas bougé d'un millimètre. Un indicateur qui s'efface quand tu t'arrêtes ne mesure pas ce que tu as construit. Il mesure ce que tu as fait cette semaine. Regarde ensuite le détail des piliers, 25 points chacun sur le tableau de bord. Celui qui note ta recherche de prospects récompense l'usage des outils de recherche de LinkedIn. Un quart du score dépend donc de la fréquence à laquelle tu utilises le produit dont LinkedIn vend la version payante. Ce n'est pas un scandale, c'est un conflit d'intérêts à lire avant d'en faire un objectif. Le point le plus gênant est ailleurs, et c'est celui que je ne vois nulle part dans les guides : le SSI compte des gestes, pas des conversations. Un commentaire vaut le même nombre de points qu'il déclenche une réponse ou non. Une invitation acceptée vaut pareil que tu parles à la personne ensuite ou jamais. La réciprocité, la seule chose qui produit un client, n'entre nulle part dans le calcul. Tu peux monter ton score avec trente minutes de commentaires par jour sans avoir parlé à un seul acheteur, et signer deux contrats ce mois-ci avec neuf messages bien visés sans que le chiffre bouge beaucoup. ## LinkedIn a rétrogradé son propre score Le 31 août 2026, la page de référence de LinkedIn sur le SSI, premier résultat sur la requête, écrit ceci mot pour mot : « Un score SSI élevé ne traduit pas toujours l'efficacité d'un commercial et ne correspond pas toujours à des résultats commerciaux concrets. En outre, le temps et les efforts requis pour obtenir des scores SSI élevés peuvent détourner l'attention des commerciaux, et les empêcher de signer des contrats et de nouer des relations solides avec les clients. » Le titre affiché en haut de la même page : « Moins de scoring, plus de ventes. » Le motif commercial est visible et je ne vais pas faire semblant du contraire : LinkedIn pousse maintenant les fonctions IA de Sales Navigator, et un score gratuit ne vend pas d'abonnement. Mais l'aveu reste rare. L'entreprise qui a inventé l'indicateur, et qui avait tout intérêt à le défendre, écrit noir sur blanc que courir après ce score détourne les commerciaux de la signature. Le score n'est pas mort : le tableau de bord fonctionne toujours, il est toujours gratuit. C'est son statut qui a changé. Il est passé d'objectif affiché à indicateur secondaire, et la moitié des pages qui rankent sur la requête enseignent encore la version d'avant. ## Les trois chiffres que je regarde à la place Trois nombres, notés le vendredi, cinq minutes. Le premier : les fils de discussion ouverts cette semaine. Une conversation compte quand l'autre a répondu deux fois. C'est un entier, il vit entre 0 et 10, et il prédit tes prochains contrats bien mieux qu'un score sur 100. Le deuxième : ton taux de réponse. Messages envoyés contre messages répondus. Sous 20 %, le problème est ton message, pas ta présence. Le SSI ne verra jamais ce ratio, parce qu'il ne regarde que ce que tu envoies. Le troisième : le nombre de publications qui ont amené au moins une conversation. Pas les vues, pas les likes. Sur dix posts, deux ou trois suffisent, mais tu veux savoir lesquels, parce que c'est là ton format. Reste la régularité, la seule chose que le SSI attrape correctement. C'est un problème de calendrier, pas de score. C'est le travail que j'ai confié à [ReadyToPost sur mes propres comptes](/fr/projects/readytopost) : il écrit, publie et répond aux commentaires, je valide. Le score monte en effet secondaire, ce qui est exactement la place qu'il mérite. Ouvre ton SSI une fois ce mois-ci, note le nombre, ferme l'onglet. Puis prends les trente minutes que tu allais consacrer à commenter pour commenter, et écris à cinq personnes dont tu as lu le dernier post en entier. ## FAQ **Où trouver son Social Selling Index ?** Sur linkedin.com/sales/ssi, avec un compte LinkedIn ordinaire. Le tableau de bord est gratuit et n'exige aucun abonnement Sales Navigator. Il affiche le score sur 100, les quatre piliers sur 25, et ton rang dans ton secteur comme dans ton réseau. **Qu'est-ce qu'un bon score SSI ?** LinkedIn te situe par rapport à ton secteur et à ton réseau plutôt que sur un seuil absolu. Au-delà de 70, tu es dans le haut des utilisateurs actifs. Aucun de ces seuils ne prédit un chiffre d'affaires : c'est un classement d'activité, pas un indicateur de vente. **Comment augmenter son SSI rapidement ?** Publier, commenter, utiliser la recherche, obtenir des invitations acceptées. Les quatre piliers réagissent en quelques jours à ces gestes. C'est justement pour cette raison que le score se gonfle facilement et qu'il ne prouve pas grand-chose sur ta capacité à vendre. **Le SSI existe-t-il encore en 2026 ?** Oui, le tableau de bord fonctionne toujours. Ce qui a changé, c'est le discours de LinkedIn autour : sa page de référence explique désormais qu'un score élevé ne garantit pas de résultats commerciaux, et oriente vers les fonctions IA de Sales Navigator. **Faut-il Sales Navigator pour avoir un bon SSI ?** Non pour consulter ton score. Mais un des quatre piliers note ta manière de chercher des prospects, et les outils de recherche avancée sont vendus avec Sales Navigator. Un quart du score est donc adossé à l'usage d'un produit payant. --- ## SSI LinkedIn : les 13 termes du tableau de bord URL: https://finngarden.com/fr/articles/ssi-linkedin Published: 2026-08-31 Language: fr Le SSI LinkedIn décodé en 13 termes : ce que compte chaque pilier, comment lire tes deux classements et où pousser pour gagner des points. Le SSI LinkedIn, ou Social Selling Index, est un score gratuit de 0 à 100, visible sur linkedin.com/sales/ssi et recalculé chaque jour. Il additionne quatre piliers plafonnés à 25 points chacun, puis affiche deux classements : ton rang dans ton secteur et ton rang dans ton réseau. Voici les treize termes qui permettent de lire ce tableau de bord sans se tromper. La plupart des pages sur cette requête expliquent quoi faire pour monter. Presque aucune ne définit ce que chaque ligne compte. C'est pourtant là que se joue la seule décision utile : où pousser, et où arrêter. ## Les six termes de l'écran principal **SSI.** L'abréviation de Social Selling Index. Un score sur 100, personnel, recalculé chaque jour à partir de ton activité récente. Recalculé veut dire qu'il redescend : ce n'est pas un acquis, c'est une photo de tes dernières semaines. Ce que ça change : tu ne peux pas atteindre un SSI une bonne fois, tu peux seulement le tenir. **Pilier.** Une des quatre familles d'activité qui composent le score, chacune notée sur 25. Le total des quatre fait le score sur 100. Ce que ça change : chaque pilier a un plafond, donc un pilier presque plein ne rapporte presque plus rien, quel que soit l'effort investi. **Marque professionnelle.** Le pilier qui note ta présence : profil rempli, photo, titre, expériences, recommandations, publications. Une partie se règle en une seule séance. Ce que ça change : c'est un chantier à faire une fois pour toutes, pas une routine hebdomadaire. **Trouver les bonnes personnes.** Le pilier qui note ta prospection : recherches lancées, profils consultés, listes de prospects. Il récompense l'usage des outils de recherche de LinkedIn. Ce que ça change : c'est le pilier le plus adossé aux produits payants de la plateforme, et il monte même si tu ne parles à personne. **Interagir avec les informations.** Le pilier qui note tes publications, tes commentaires, tes partages et tes messages. Le libellé exact varie selon les versions de l'interface, l'idée ne bouge pas : prends-tu la parole, réagis-tu. Ce que ça change : c'est le pilier qui exige de la régularité, donc le premier à décrocher dès qu'une semaine chargée arrive. Sur mes propres comptes, [ReadyToPost tient ce calendrier](/fr/projects/readytopost) : il publie et répond aux commentaires, je valide. **Établir des relations.** Le pilier qui note ton réseau : invitations envoyées et surtout acceptées, connexions avec des décideurs, taille du carnet. Ce que ça change : c'est le seul pilier où l'accord d'un tiers est nécessaire, donc le plus lent, donc celui qu'on abandonne. ## Les deux classements, et pourquoi ils bougent sans toi **Rang dans ton secteur.** Ta position en pourcentage parmi les utilisateurs LinkedIn de ton industrie, affichée sous la forme « tu es dans les X % du haut ». Ce que ça change : c'est un classement, pas une note. Si ton secteur devient plus actif, tu descends sans avoir rien changé à ton comportement. **Rang dans ton réseau.** La même mesure, mais parmi tes propres relations. Ce que ça change : plus ton réseau est peuplé de gens très actifs, plus ton rang paraît médiocre à activité constante. Un rang bas dans un réseau de créateurs de contenu ne dit pas la même chose qu'un rang bas dans un réseau de dirigeants discrets. La distinction à garder en tête : le score dépend de toi, le rang dépend aussi des autres. Les deux sont affichés côte à côte sur le même écran, et c'est la confusion la plus fréquente. Quand quelqu'un dit « mon SSI a baissé », il parle neuf fois sur dix de son rang. ## Le vocabulaire d'à côté **Social selling.** La pratique que le score prétend mesurer : utiliser un réseau social pour identifier des acheteurs, se rendre visible auprès d'eux et ouvrir la conversation, plutôt que d'appeler dans le vide. Ce que ça change : le social selling est une méthode commerciale, le SSI n'en mesure que la partie visible sur la plateforme. **Sales Navigator.** L'abonnement payant de LinkedIn dédié à la prospection : recherche avancée, listes de prospects, alertes. Le tableau de bord SSI, lui, est gratuit et ne l'exige pas. Ce que ça change : tu peux consulter ton score sans payer, mais le pilier prospection est bâti sur des gestes que cet abonnement industrialise. **Lead sauvegardé.** Un prospect ajouté à une liste de suivi dans Sales Navigator, pour recevoir ses changements de poste et ses publications. Ce que ça change : c'est une action de veille, elle nourrit le pilier prospection alors qu'elle ne produit, à elle seule, aucune conversation. **InMail.** Le message payant vers une personne hors de ton réseau, décompté d'un quota mensuel de crédits. Ce que ça change : l'InMail appartient au vocabulaire Sales Navigator, pas à celui du SSI. Ton tableau de bord affiche des piliers, pas des crédits. Et un InMail se rédige comme un message à froid, avec les règles que j'ai réunies dans [mes douze notes de terrain sur le cold-emailing](/fr/articles/cold-emailing) : court, une seule demande, aucune flatterie. **Taux d'acceptation.** La part de tes invitations qui sont acceptées. Le tableau de bord ne l'affiche pas : tu le calcules toi-même, invitations envoyées contre invitations acceptées. Ce que ça change : c'est le chiffre qui explique le pilier relations quand il stagne, et le seul de cette liste que LinkedIn te laisse dans l'ombre. ## L'arbitrage que le tableau de bord ne te souffle pas Le plafond de 25 points a une conséquence que je n'ai vue écrite nulle part dans les guides en place sur cette requête. Ouvre tes quatre piliers et regarde-les comme des réservoirs, pas comme des notes. Un pilier à 22 sur 25 ne peut plus te rendre que 3 points, même si tu y passes ton mois. Un pilier à 9 en contient 16 disponibles. Ce n'est pas une intuition, c'est de l'arithmétique de plafond. Et le réflexe va systématiquement dans le mauvais sens. On pousse le pilier où on est déjà bon, parce que c'est le geste agréable : celui qui publie déjà publie plus, celui qui a un profil soigné le repolit. Le pilier à 9 est presque toujours « établir des relations », parce que c'est le seul qui demande qu'un inconnu clique sur accepter, et donc le seul qui ne dépend pas que de ta volonté. L'ordre de travail se déduit tout seul : le pilier le plus bas d'abord, jusqu'à ce qu'il rejoigne les autres. Passé 20 sur un pilier, ton temps vaut mieux ailleurs. Reste à savoir si ce score mérite l'effort. J'y ai répondu ailleurs, et la réponse vient de la plateforme elle-même : [LinkedIn a lâché son propre score](/fr/articles/social-selling-index). Le glossaire ci-dessus sert dans les deux cas, puisqu'il dit ce que chaque geste alimente. Ouvre le tableau de bord, note tes quatre nombres sur 25, choisis le plus bas, et ignore les trois autres pendant trente jours. ## FAQ **SSI et Social Selling Index, est-ce la même chose ?** Oui. SSI est l'abréviation de Social Selling Index, le nom complet du score. Les deux expressions désignent le même tableau de bord, accessible sur linkedin.com/sales/ssi avec un compte LinkedIn ordinaire. **À quelle fréquence le SSI est-il mis à jour ?** Chaque jour, à partir de ton activité récente. C'est pour cette raison qu'il descend pendant les vacances : il photographie tes dernières semaines, il ne cumule pas ce que tu as construit depuis cinq ans. **Pourquoi mon SSI a baissé alors que je n'ai rien changé ?** Regarde d'abord s'il s'agit du score ou du rang. Le score sur 100 suit ton activité, donc une semaine calme le fait reculer. Le rang est relatif : il baisse quand ton secteur ou ton réseau s'active plus que toi, sans que ton comportement ait bougé. **Quel pilier du SSI fait gagner le plus de points ?** Celui où tu es le plus bas, mécaniquement, puisque chaque pilier plafonne à 25. Un pilier déjà à 22 ne contient plus que 3 points à prendre, quel que soit l'effort investi. **Mon SSI est-il visible par les autres ?** Non. Le tableau de bord est privé, le score n'apparaît pas sur ton profil et personne n'est prévenu quand il monte ou descend. C'est un indicateur pour toi seul, ce qui ôte tout intérêt à l'afficher dans une bio.